OAuth 2.0
OAuth 2.0

OAuth 2.0

 
OAuth 2.0 is an industry-standard authorization framework that enables third-party applications to obtain limited access to a user's resources without exposing their credentials.
 
 
OAuth 2.0 is an authorization framework that allows an application to access resources hosted by other web applications on behalf of a user. It provides consented access and restricts the actions a client app can perform on resources on behalf of the user without sharing the user's credentials. OAuth 2.0 is not an authentication protocol; it is designed to grant access to resources like APIs or user data.
 
OAuth2.0 Key Roles
  • Resource Owner: The entity (usually the end-user) that can grant access to protected resources.
  • Resource Server: The server hosting the protected resources.
  • Client: An application requesting access to a protected resource on behalf of the resource owner. Clients can be public (e.g., a JavaScript app) or confidential (e.g., a server-side app).
  • Authorization Server: The server that authenticates the resource owner and issues access tokens after obtaining proper authorization.
 
notion image
 
  • User Initiates Login: The user starts the authentication process by interacting with the client application.
  • Client Redirects to Keycloak: The client redirects the user to Keycloak for authentication.
  • Keycloak Presents Login Page: Keycloak displays the login interface to the user.
  • User Enters Credentials: The user submits their authentication details.
  • Keycloak Redirects with Authorization Code: Upon successful authentication, Keycloak redirects the user back to the client with an authorization code.
  • Client Exchanges Code for Access Token: The client sends the authorization code to Keycloak to obtain an access token.
  • Keycloak Returns Access Token: Keycloak issues an access token to the client.
  • Client Requests Resource with Access Token: The client uses the access token to request the protected resource from the resource server.
  • Resource Server Returns Requested Resource: The resource server validates the access token and, if valid, returns the requested resource to the client.
 
Explanation of the Flow
  1. Authorization Request: The process begins when the Resource Owner (user) initiates an authorization request by attempting to access a resource. The Client (application) redirects the user to the Authorization Server (Keycloak) to obtain permission.
  1. Authorization Grant: The user is presented with a login screen by Keycloak. Upon successful authentication, the user is asked to grant permission to the Client to access their resources. If the user consents, Keycloak issues an Authorization Grant (e.g., an authorization code).
  1. Authorization Code: In the case of the Authorization Code flow, the Authorization Grant is typically an authorization code that the Client will use to request an access token.
  1. Token Request: The Client sends a request to the Authorization Server (Keycloak) to exchange the Authorization Code for an Access Token. This request includes the Authorization Code, Client ID, Client Secret, and redirect URI.
  1. Access Token Response: If the request is valid, Keycloak responds with an Access Token (and optionally a Refresh Token). The Access Token is a credential that the Client can use to access protected resources on behalf of the Resource Owner.
  1. Resource Request: The Client uses the Access Token to make requests to the Resource Server (the API or service that the user wants to access). The Access Token is included in the request headers.
  1. Resource Response: The Resource Server validates the Access Token with Keycloak. If the token is valid, the Resource Server responds with the requested resource.
 
Access Token
An access token is a piece of data that represents the authorization to access resources on behalf of the end-user. Access tokens do not have a specific format, but JSON Web Token (JWT) is often used. For security reasons, access tokens may have an expiration date.
 

 
OpenID Connect (OIDC)
OpenID Connect (OIDC) is an identity layer built atop the OAuth 2.0 protocol, enabling clients to verify user identities and access basic profile information. It addresses the need for standardized, interoperable user authentication across applications. OIDC operates by having clients authenticate users via an authorization server, which then issues ID tokens containing user information. In Keycloak, OIDC is implemented to manage user authentication and authorization, allowing seamless integration with various applications and services.
The ID token issued in OIDC is a JSON Web Token (JWT) that contains claims—name/value pairs—about the authentication event and the authenticated user. Standard claims include:
  • iss: Issuer Identifier for the entity that issued the token.
  • sub: Subject Identifier, a unique identifier for the user.
  • aud: Audience, the intended recipient of the token.
  • exp: Expiration time on or after which the token must not be accepted.
  • iat: Issued-at time, indicating when the token was generated.
Additional claims can provide user details such as name, email, and preferred_username, depending on the scopes requested during authentication. These claims enable client applications to obtain necessary user information without additional API calls.
 

Keycloak

Keycloak is an open-source identity and access management server. It provides features like single sign-on (SSO), user authentication, authorization, and user management for applications, acting as a central hub to secure and manage user access.
Realm (in Keycloak)
In Keycloak, a realm is a security domain. It provides a way to manage a set of users, roles, and clients. Realms allow you to create isolated environments within Keycloak.
Creating a Realm (in Keycloak):
While specific steps may vary with Keycloak versions, the general process involves using the Keycloak admin console to create a new realm and configure its settings.
Client (in Keycloak)
In Keycloak, a client(aka Application) is an entity that can request authentication of a user. Clients typically represent applications or services that need to authenticate users.
User (in Keycloak)
A user in Keycloak represents an individual who can authenticate and access resources within a realm.
Client Protocol (in Keycloak)
The client protocol defines the protocol used by the client to communicate with Keycloak. Common protocols include OpenID Connect and SAML.
Access Type (in Keycloak)
The access type determines how the client obtains access tokens. Options include:
  • Confidential: Used for server-side applications where the client secret can be securely stored.
  • Public: Used for client-side applications where the client secret cannot be securely stored.
  • Bearer-only: The client only retrieves access tokens and does not perform any authentication itself.
Redirect URI (in Keycloak)
The redirect URI is the URI to which Keycloak redirects the user after successful authentication. This URI must be registered with the client in Keycloak.
 
Built with Potion.so