This is the first blog post of the OAUTH2.0 sessions where we will try to go in deep and understand the standard, flows, problems that it solves and the specific implementations that exists out there together with their limitations.
The main aim of this post is to lay the foundation of the standard and the key terminology that is required to understand the concepts.
OAuth is a standard that apps can use to provide client applications with “secure delegated access”. OAuth works over HTTPS and authorizes devices, APIs, servers, and applications with access tokens rather than credentials. OAuth 2.0 defines mechanisms to obtain and use access tokens to access protected resources, but they do not define standard methods to provide identity information.
OAuth 2.0 is not about authentication or authorization, but delegation.
• It allows a resource owner to delegate access to a protected resource to a client
• The authorization server plays a central role in establishing that delegation. Making a proper authorization decision requires careful attention to detail
• Authorization is the responsibility of the resource server
• It uses the access token to make authorization decisions on incoming requests
OpenID Connect implements authentication as an extension to the OAuth 2.0 authorization process. It provides information about the end user in the form of an id_token that verifies the identity of the user and provides basic profile information about the user.
• OpenID Connect is about delegating authentication to a third-party
• OIDC flows result in an identity token containing properties about the authentication
• OIDC combines with OAuth 2.0, as the same flow can also issue access tokens
• OpenID Connect is our recommendation if you are building a web application that is hosted on a server and accessed via a browser.
The actors in OAuth flows are as follows:
Resource Owner: owns the data in the resource server. For example, I’m the Resource Owner of my Facebook profile.
Resource Server: The API which stores data the application wants to access. Lets say, the Facebook open profile information microservice.
Client: the application that wants to access your data. Lets say this website.
Authorization Server: The main engine of OAuth
Terminology:
Access Tokens:
Access Tokens are credentials that can be used by an application to access an API.
Access Tokens can be an opaque string, JWT, or non-JWT token(depends on the implementation). Its purpose is to inform the API that the bearer of this token has been granted delegated access to the API and request specific actions (as specified by the scopes that have been granted). https://tools.ietf.org/html/rfc6749#section-1.4
Bearer Tokens:
Bearer Tokens are Access Tokens
When sending the access token in the "Authorization" request header field defined by HTTP/1.1 [RFC2617], the client uses the "Bearer" authentication scheme to transmit the access token. https://tools.ietf.org/html/rfc6750
ID Tokens:
The ID Token is a JSON Web Token (JWT) that contains identity data. It is consumed by the application and used to get user information like the user's name, email, and so forth. ID Tokens can contain roles and groups in the case of Microsoft AAD. Their main use is for authentication. ID tokens are issued based on the Open ID connect standard.
ID Tokens conforms to an industry standard (IETF RFC 7519) and contain three parts: a header, a body and a signature.
Scope:
A mechanism that determines actions applications can perform on a user's behalf with information previously created in an online resource. For example: Read facebook public profile information
JWT:
Json Web Tokens are a way of Encrypting/Signing JSON payloads
... enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. https://tools.ietf.org/html/rfc7519
Claims:
JWT Tokens contain claims, which are statements (such as name or email address) about an entity (typically, the user) and additional metadata.
AUTH2.0 flows overview
OAUTH 2.0 when to use each flow
SAML limitations
SAML is basically a session cookie in your browser that gives you access to webapps. It’s limited in the kinds of device profiles and scenarios you might want to do outside of a web browser.
When SAML 2.0 was launched in 2005, it made sense. However, a lot has changed since then. Now we have modern web and native application development platforms. There are Single Page Applications (SPAs) like Gmail/Google Inbox, Facebook, and Twitter. They have different behaviors than your traditional web application, because they make AJAX (background HTTP calls) to APIs. Mobile phones make API calls too, as do TVs, gaming consoles, and IoT devices. SAML SSO isn’t particularly good at any of this.
References:
Comments