Authorization vs Authentication
Authentication is the process of verifying the identity of a user by obtaining some sort of credentials and using those credentials to verify the user’s identity.
Authorization is the process of allowing an authenticated users to access the resources by checking whether the user has access rights to the system.Authorization helps you to control access rights by granting or denying specific permissions to an authenticated user.
Nonrepudiation is the assurance that someone cannot deny something.
Typically, non repudiation refers to the ability to ensure that a party to a contract or a communication cannot deny the authenticity of their signature on a document or the sending of a message that they originated.
Token based Authentication
Instead of having to authenticate with username and password for each protected resource, the user authenticates that way once (within a session of limited duration), obtains a time-limited token in return, and uses that token for further authentication during the session.
Token based authentication works by ensuring that each request to a server is accompanied by a signed token which the server verifies for authenticity and only then responds to the request.
Use of tokens
Tokens are stateless : The token is self-contained and contains all the information it needs for authentication. This is great for scalability as it frees your server from having to store session state.
Tokens can be generated from anywhere : Token generation is decoupled from token verification allowing you the option to handle the signing of tokens on a separate server or even through a different company such us Auth0.
Fine-grained access control : Within the token payload you can easily specify user roles and permissions as well as resources that the user can access.
JSON Web Token
JWT is really just a hash of data encoded into a compact format with a header and an optional signature, but JWTs have several features that make them well-suited for data exchange:
- JWTs are easy to parse and contain structured data in the widely supported JSON format.
- JWTs are compact and therefore may be used in URLs and HTTP headers.
- JWTs may be digitally signed and encrypted, making them appropriate for trusted exchange of potentially sensitive data.
- JWT has gained mass popularity due to its compact size which allows tokens to be easily transmitted via query strings, header attributes and within the body of a POST request.
- A JSON Web Token consists of three parts: Header, Payload and Signature.
- The header and payload are Base64 encoded, then concatenated by a period,finally the result is algorithmically signed producing a token in the form of header.claims.signature.
- The header consists of metadata including the type of token and the hashing algorithm used to sign the token.
- The payload contains the claims data that the token is encoding.
- The signature is the string that is the output of some Hash algorithm which denotes the integrity of the token. But without the correct secret key, we cannot verify the signature.
Example of jwt token:
Note : Tokens are signed to protect against manipulation, they are not encrypted.
What this means is that a token can be easily decoded and its contents revealed.
In a real world scenario, a client would make a request to the server and pass the token with the request.The server would attempt to verify the token and, if successful, would continue processing the request. If the server could not verify the token, the server would send a 401 Unauthorized and a message saying that the request could not be processed as authorization could not be verified.
These are strings, sent as part of the scope request parameter.
In other words, the key value pairs which we get after decoding a JWT token
The client provides the scope information while requesting access token.
Scope is a string that identifies a specific unit of access that may be granted to a client.
Scopes must be mutually understood by the client, the authorization/authentication server, and the resource server.
The attributes included in the issued token can be controlled with the scope parameter as follows:
- scope=openid will only return iss, sub, aud, exp and iat claims.
- scope=openid email nickname favorite_food will return claims for openid in addition to the email, nickname and favorite_food fields if they are available.
- scope=openid profile will return all the user attributes in the token.
- Types of scopes:
1)Generic scopes — A scope that is notassociated with a resource type or attribute.
2) Authenticated identity scope — A scope that is associated with one or more attributes for the identity resource type. Applies to a single user only.
3) Resource scope — A scope that is associated with one or more attributes for arbitrary resource type. Applies to any resource of the specified resource type
The ID token is a JSON Web Token (JWT) that contains user profile information (like the user’s name, email, and so forth), represented in the form of claims.
These claims are statements about the user, which can be trusted if the consumer of the token can verify its signature.
The ID token is consumed by the client and the claims included, are typically used for UI display.
The attributes or claims included in the issued ID token are controlled by the use of a parameter called scope.
The access token is a credential representing an end user’s authorization for the client to access the user’s resources on the user’s behalf. By using access tokens, clients are able to access scoped user data without requiring the user to divulge his or her password to the client.
Access tokens expire after a time and can also be revoked, client access can be managed and abuses can be avoided or mitigated easily.
Once an access token is in the client’s possession, it must be stored securely and confidentially, as a resource server will accept the token as proof of authorization from any party until the token expires or is revoked.
Validation of Access token
Depending on its needs, a client may not need to validate an access token. For example, it may simply use an access token until it is no longer accepted by the resource server, at which point it can request another token from the authentication server.
A resource server must always validate an access token before accepting it.
Two options are available for validating access tokens.
1)The token validation endpoint
An access token may be validated by submitting it to the Auth system’s token validation endpoint, also called the token introspection endpoint.
This is a simple POST request to /oauth/validate.
2) JWT access token validation
- All access tokens issued by the Auth systems are signed JWTs.
- A client or resource server can therefore determine if an access token is still active by simply decoding the token and checking its expiration time (exp) claim.
- The token’s signature should also be verified to ensure its authenticity. Access tokens issued by the Auth system are always signed using an RSA-based JWA,
- so the verifying entity must have a copy of the Broker’s public signing key. This can be obtained out of band, or it may be obtained dynamically through the JWKS.
- In the latter case, it will typically be advisable to cache the downloaded JWKS, updating it periodically.
- Validating an access token as a JWT has a decided advantage over using the Data Governance Broker’s token validation endpoint:
- It doesn’t require the client or resource server to make a request over the network.
- The disadvantage, however, is that the client or resource server cannot know if a token has been revoked.This can be mitigated by configuring a short expiration period for access tokens.
A Refresh Token is a special kind of token that can be used to obtain a renewed access token — that allows accessing a protected resource — at any time. You can request new access tokens until the refresh token expires.
Refresh tokens must be stored securely by an application because they essentially allow a user to remain authenticated forever.
Rules in Auth0
Rules can be used to:
- Profile enrichment: query for information on the user from a database/API, and add it to the user profile object.
- Normalize attributes from different providers beyond what is provided by Auth0.
- Reuse information from existing databases or APIs for migration scenarios.
- Keep a white-list of users and deny access based on email.
- Notify other systems through an API when a login happens in real-time.
- Enable counters or persist other information.
- Enable multifactor authentication, based on context (e.g. last login, IP address of the user, location, etc.).