Within the universe of
Authorization to third parties using the traditional model, where the client accesses a protected resource using the resource owner’s credentials, has associated with it a number of issues and limitations as the owner will have to share their credentials with third parties [1]:
- Credentials need to be stored in third-party applications for future use.
- Servers will be required to support authentication.
- Third-party applications gain access to all protected resources of the resource owner, leaving them unable to restrict the duration or access to a limited subset of resources.
- The resource owner cannot revoke access to a third party without revoking access to all others and this is only possible by changing the password.
- The security breach in third-party applications results in the exposure of credentials and all data protected by the third party.
To mitigate these problems, two mechanisms stand out, OAuth and token-based access
Microservices Security Mechanisms – Oauth 2.0
OAuth is an open standard that allows authorized client access to resources made available by a server. The OAuth standard also provides methods for customers to authorize third-party access to resources and information they own, which is made available by a server without having to enter or share that user’s access credentials.
The problems and limitations identified in the traditional authorization model are addressed by this standard by introducing the authorization layer, separating the role of the client from the resource owner. The client requests access to resources owned by the resource owner hosted on the resource server and different credentials are issued than those of the resource owner. Instead of using the resource owner’s credentials to access protected resources, the client obtains an access token that indicates a specific scope, time, and other access attributes, which tokens are issued with the approval of the resource owner. The client uses the access token to access protected resources hosted by the resource server (Figure 1) [1].
OpenID Connect
OpenID Connect builds on top of OAuth2 and adds authentication. OpenID Connect adds some constraints to OAuth2 like UserInfo Endpoint, ID Token, discovery and dynamic registration of OpenID Connect providers, and session management.
It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User.
OpenID Connect allows clients of all types, including Web-based, mobile, and JavaScript clients, to request and receive information about authenticated sessions and end-users. The specification suite is extensible, allowing participants to use optional features such as the encryption of identity data, the discovery of OpenID Providers, and session management.
Microservices Security Mechanisms – Token-based
On the other hand, Token-based authorization is less complex and unlike OAuth is not a standard.
The client accesses the server by sending the access credentials, the service provider validates the credentials, saves an authorization token on success, associates the token with the client address, and assigns the lifetime of this access token. The service sends a success message to the customer along with the token. The client starts to invoke the services on the server by sending the authorization token, where the server will validate each request, checking if the token is valid (Figure 2).
JWToken
JWT tokens are JSON-encoded data structures that contain information about the issuer, subject (claims), expiration time, access token, refresh token, id token, and so on.
It is signed for tamper proof and authenticity and it can be encrypted to protect the token information using a symmetric or asymmetric approach. JWT is simpler than SAML 1.1/2.0 and supported by all devices
References
[1] “The OAuth 2.0 Authorization Framework rfc6749,” 2012.
[2] “Cookies vs Tokens: The Definitive Guide,” 2016.