OAuth 2.0 Authorization Security Framework
OAuth2.0 is a security protocol that enables you, the user, to use your user name and password from your patient portal to pull in your data from multiple different sources.
The protocol protects your user name and password from applications like OneRecord and data access can be limited to specific types of data, and can be revoked by you at any time. You can read more about about it here.
To get access to your protected data known as resources - OAuth 2.0 uses Access Tokens. An Access Token is a string representing the granted permissions.
Access Token Format
By default, Auth0 generates Access Tokens, for API Authorization scenarios, in JSON Web Token (JWT) format. JWTs contain three parts: a header, a payload, and a signature:
The header contains metadata about the type of token and the cryptographic algorithms used to secure its contents.
The payload contains a set of claims, which are statements about the permissions that should be allowed, and other information like the intended audience and the expiration time.
The signature is used to validate that the token is trustworthy and has not been tampered with.
In any OAuth 2.0 flow we can identify the following roles:
Resource Owner: the entity that can grant access to a protected resource. Typically this is the end-user.
Resource Server: the server hosting the protected resources. This is the API you want to access.
Client: the app requesting access to a protected resource on behalf of the Resource Owner.
Authorization Server: the server that authenticates the Resource Owner, and issues Access Tokens after getting proper authorization. In this case, Auth0.
We will now have a more detailed look on how the protocol works. As we will see in a while, OAuth has many "flavors" (called authorization grant types) that you can use. For now we will have a more generic look into the flow.
The Application (Client) asks for authorization from the Resource Owner in order to access the resources.
Provided that the Resource Owner authorizes this access, the Application receives an Authorization Grant. This is a credential representing the Resource Owner's authorization.
The Application requests an Access Token by authenticating with the Authorization Server and giving the Authorization Grant.
Provided that the Application is successfully authenticated and the Authorization Grant is valid, the Authorization Server issues an Access Token and sends it to the Application.
The Application requests access to the protected resource by the Resource Server, and authenticates by presenting the Access Token.
Provided that the Access Token is valid, the Resource Server serves the Application's request.
If you have any questions or concerns please contact us via the "help button" in the bottom right hand corner of the screen or email us at email@example.com.