Debunking Sessions, Tokens and Beyond…
We’ve all had experiences logging in to multiple websites(gmail, facebook, quora, spotify etc.) to e-mail, check our friend feed, listen to music, basically to access content and resources customized exclusively for us. In order to access these personalized content, we as an internet user require proving our identity successfully to the server which hosts this content. To prove one’s identity, attributes such as username, password, mfa, biometrics, ipAddress etc. are provided to the server. While the user is trying to prove one’s identity and access the resources and their content on the server, they are basically being authenticated and authorized by the server. Behind the scenes, there is a creation and exchange of multiple entities(called tokens,) between the server and the application user uses(,like browser through which we access gmail, spotify).
After having worked in AWS Identity for some time now, I got ample opportunities to deal with systems implementing user authentication, authorization and session management, utilizing different types of protocols and tokens. This blog is an attempt to simplify the understanding of some prevalent authentication and authorization related tokens with examples.
JWT:
Simply put, it is an encoded string with JSON payload transferrable over web.
Official definition per RFC7519, JSON Web Token (JWT) is a means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure.
- Enables claims to be digitally signed(for authenticity) or encrypted(for integrity and confidentiality). Thus, making JWTs URL safe since they can’t be tampered with,
- One can use an algorithm like HMAC SHA-256 for signing or use algorithm like GCM_AES256 for both signing and encryption,
- Compact- usually bounded by a fixed length,
- URL safe, since the JWT string is signed,
- JWT claim set is a json object conveying the claims from a party.
JWT claim set eg:
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}Session:
A user session is established while a user is trying to access server resources. It is one of the ways to keep track of user requests to the server as well as keep track of changing user identity and gaining confidence in the identity being claimed by the end user. Usually, the end user receives a session token in the form of sessionId or JWT string which can be used as a session cookie once they are authenticated(after having provided sufficient proof of the identity they are claiming as to the resource server).
- Session tokens: These are unique JWT strings associated with an end user session.
- The user session is tied to the user-agent(browser, CLI, native app clientId) tied to the user device, from where the user request originated,
- Usually(but not always) has an expiration time set after which the token is no longer accepted by the resource server,
- Sessions can be modeled as client-side with all session information state encoded in the session token string or as server side, where the session state is stored on the server(DataBase) and the user receives a session token string with reference to that session state. By storing sessions with server side state, one can enable features such as listing and deleting of sessions.
OAuth tokens
OAuth is an open standard for access delegation, commonly used as a way for users to grant websites or applications access to their information on other websites without any exchange of credentials from the user. This is the protocol used when logging into apps like Spotify with your facebook account, and allowing you to import all your facebook friends to follow on spotify.
Access tokens: Access tokens are opaque(typically JWT like) strings that applications use to make API requests on behalf of a user. The access token represents the authorization of a specific application to access specific(scoped down) parts of a user’s data.
Refresh tokens: These are tokens backing access token, used by OAuth client to refresh/request a new access token without user’s interaction. The refresh token only grants the scoped down permissions tied to access token.
Experiment different grant types in OAuth2.0 here-
https://github.com/cloudentity/oauth2c
OIDC tokens
OpenID Connect, is a user federation authentication protocol built on top of OAuth2.0. This is used to signin a user with an Idp(for eg google, fb) and be able to access user resources hosted on a server without sharing any sign in credentials.
In addition to granting Access token, refresh token, it typically generates an OIDC Identity token, caching the user profile information to be passed to the client application.
SAML Tokens
SAML is another authentication protocol, independent of OAuth, relying on an exchange of messages to authenticate in XML SAML format, as opposed to JWT. It is more commonly used to help enterprise users sign in to multiple applications using a single sign on(or SSO).
