OAuth2

tags: SSO

Summary fc #

The OAuth (open authorization) protocol was developed by the Internet Engineering Task Force and enables secure delegated access.

It lets an application access a resource that is controlled by someone else (end user).
This kind of access requires Tokens, which represent delegated right of access.
That’s why applications get access without impersonating the user who controls the resource.
impersonation(sharing credentials) vs delegation (delegated right of access)

Basic Diagrams #

The authorization server verifies the identity of the user then issues access tokens to the application.

Code Flow #

Definition #

The code flow is the most advanced flow in OAuth. It is also the most flexible, that allows both mobile and web clients to obtain tokens securely. It is split into two parts, the Authorization flow that runs in the browser where the client redirects to the OAuth server and the OAuth server redirects back when done, and the Token flow which is a back-channel call from the Client to the Token endpoint of the OAuth server. ref

The OAuth 2.0 authorization code flow is described in section 4.1 of the OAuth 2.0 specification. It’s used to perform authentication and authorization in the majority of app types, including single page apps, web apps, and natively installed apps. ref

Authorization code flow - more secure #

ref

Difference between redirect URI and callback URI or URL?

Why redirect URI? #

Redirect URLs are a critical part of the OAuth flow. After a user successfully authorizes an application, the authorization server will redirect the user back to the application with either an authorization code or access token in the URL. Because the redirect URL will contain sensitive information, it is critical that the service doesn’t redirect the user to arbitrary locations. ref

This is the reason the redirect URI should be mentioned in the IdP while creating an account for the SP in IdP

Implicit flow - frontend only, less secure #

What flow(grant type) to use? #

Web application #

Native mobile app #

SPA with API backend #

SSO 3rd party #

Token validation #

Vocabulary #

Resource Owner(user) #

The resource owner is the user who authorizes an application to access their account. The application’s access to the user’s account is limited to the scope of the authorization granted (e.g. read or write access)

Client #

The client is the application that wants to access the user’s account. Before it may do so, it must be authorized by the user, and the authorization must be validated by the API.

In OAuth terminology, a client is an application that requests tokens from an authorization server.
The client uses these tokens to access protected resources on a resource server.
A client could be a web application, mobile application, server-side application, etc.

Resource Server #

Integrated Application #

Authorization Server #

(WSO2 IAM)

Authorization grant #

One of the grant types Grant Types

Access token #

Scope #

Back channel(secure) #

Communication between backend app and authorization server

Front channel(less secure) #

Communication between frontend app(browser or mobile app) and authorization server

Use Case OAuth2 and SAML #

tags

diff, Use Cases

SAML is typically used for SSO in government and enterprise applications (identity management), where backend system processing of XML is commonplace. Many government citizen ID schemes (e.g., UK Verify) are SAML based.
OAuth2 is widely used in consumer and enterprise applications, both in authorization and authentication roles.
- It is typically used to authorize access to RESTful APIs, where its use of access tokens makes it simple and attractive.
SAML is not a good protocol to implement authentication and authorization for REST APIs.
- verbose and inefficient