Barbarian Meets Coding
barbarianmeetscoding

WebDev, UX & a Pinch of Fantasy

8 minutes readidentitydraft

Identity Management

A rpg character sheet with an image of a human female warrior and a collection of skills and attributes
Identity management is a family of technologies, protocols and policies to ensure that the right users have appropriate access to technology resources.

Identity management is a family of technologies, protocols and policies to manage and control access to resources like computer systems, applications and data. It involves the administration of user identities, authentication and authorization.

The main goal of identity management is to ensure that only authorized users have access to sensitive data and resources, while preventing unauthorized access and data breaches. This involves managing user accounts, passwords, permissions, and other access controls.

Glossary

  • Identity: Digital representation of a user’s identity which includes attributes such as name, email, username, password, and other personal or sensitive data. In addition to basic user information, identity management systems may also include additional user attributes such as roles, permissions, and group memberships (these are also referred to as claims)
  • Identifier: Unique piece of data that is used to uniquely identify a digital entity, such as a user, device, application, or service. e.g. a user may be assigned a unique identifier, such as a username or email address used to authenticate and authorize access to resources and services.
  • Authentication: Verifying the identity of a user who is trying to access a system, service, or application. A user can authenticate through a combination of factors such as passwords, biometric data, devices or security tokens.
  • Authorization: Determining what resources a user is authorized to access and what actions they are authorized to perform.
  • Identity federation: Linking different identity systems and providing a seamless experience to users across multiple systems and applications.
  • Single sign-on (SSO): The ability to allow users to log in (authenticate) once and access multiple applications or services without having to authenticate each time.
  • Claim: A statement or piece of information about an entity (such as a user or an application) that is being authenticated. A claim is typically a piece of information that the entity asserts about itself or that is asserted about the entity by a trusted authority (e.g. a name, email, role, etc).
  • OAuth 2.0: Authorization protocol that allows users to grant third-party applications limited access to their resources on another website or application without sharing their credentials. It provides a secure and standardized way for users to authorize access to their resources to another party. As a practical example, using OAuth you can give a photo printing app access to view your photos in Google Photos (but not edit or delete them).
  • OpenID Connect (OIDC): Protocol that provides a standardized way for users to authenticate and get access to web applications. It is an extension of the OAuth 2.0 protocol, which is used for granting third-party access to web resources without sharing user credentials.
  • JSON Web Token (JWT): JSON Web Token (or JWT) is a compact way of representing claims to be transferred between two parties in the shape of JSON objects, base64 encoded and cryptographically signed.

JSON Web Token (JWT)

JSON Web Token (or JWT) is a compact way of representing claims to be transferred between two parties.

A JWT is composed of three parts: a header, a payload, and a signature. The header identifies the algorithm used to sign the token, the payload contains the claims or information being transmitted, and the signature is used to verify the integrity of the token.

A sample JWT can look like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

where each part of the JWT is base64 URL encoded and separated by a dot.

// header
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
// payload
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
// signature
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

When decoded the JWT reveals the header and payloads to be a JSON object:

// header (algorithm and token type)
{
  "alg": "HS256",
  "typ": "JWT"
}
// payload (claims)
{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}
// signature
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Because the information within a JWT is digitally signed, it can be verified by the recipient to ensure that the message has not been tampered with and that the sender is who they say they are.

The JWT standard is often used for authentication and authorization purposes in web applications and APIs (in protocols like OAuth2 or OIDC). When a user logs in to an application, the server creates a JWT containing the user’s identity information and sends it to the client. The client can then include the JWT in subsequent requests to the server, allowing the server to verify the user’s identity and grant access to protected resources.

JWTs are widely used because they are lightweight, easy to use, and can be transmitted over any network protocol. They are also highly extensible and can be used to transmit any type of information, making them a versatile solution for many types of applications.

OAuth 2.0

OAuth 2.0 is an authorization protocol that allows users to grant third-party applications limited access to their resources on another website or application without sharing their credentials. It provides a secure and standardized way for users to authorize access to their resources to another party.

Granting permissions to a series of resources using OAuth 2.0 follows these rough steps:

  1. The user first grants permission to the third-party application to access their resources on a particular website or application
  2. The user is redirected to the authorization server, where they can approve or deny the request for access
  3. Once the user approves the request, the authorization server issues an access token to the third-party application, which can then use that token to access the user’s resources.

The access token is often encoded as a JWT (JSON web token) and contains a series of claims that represent access to a given resource (in the from of scopes). The token is usually time-limited and can be revoked by the user or the authorization server at any time.

OAuth 2.0 is widely used by social media sites, such as Facebook, Twitter, and Google, to allow users to sign in to third-party applications using their social media credentials. It is also used by APIs to allow access to protected resources.

OpenID Connect (OIDC)

OpenID Connect (commonly referred to as OIDC), is a protocol that provides a standardized way for users to authenticate and get access to web applications. It is an extension of the OAuth 2.0 protocol, which is used for granting third-party access to web resources without sharing user credentials.

OIDC adds an authentication layer on top of OAuth 2.0, providing a framework for user authentication and identity verification. It allows users to log in to a web application using their existing identity provider credentials (such as Google, Facebook, Twitter, GitHub or Microsoft), without having to create a separate username and password for that application.

The OIDC protocol uses JSON Web Tokens (JWTs) to encode and transmit identity information between the identity provider and the application in the form of identity tokens. This enables the application to verify the identity of the user and retrieve additional user information such as name, email, and profile picture (fields commonly known as claims).

Like other JWT, the id token contains a header, a payload and a signature. The id token payload contains a number of claims that

Discovery

The OIDC configuration for a authorization server (also known as OIDC provider) is public and published under:

https://{authorization-server-domain}/.well-known/openid-configuration

The configuration itself is a JSON document that can look like this:

{
  // URL https scheme with no query or fragment component that 
  // the OP (OIDC Provider) asserts as its Issuer Identifier
   "issuer":"https://dev-50h8ivwoimbp1mma.us.auth0.com/",
   "authorization_endpoint":"https://dev-50h8ivwoimbp1mma.us.auth0.com/authorize",
   "token_endpoint":"https://dev-50h8ivwoimbp1mma.us.auth0.com/oauth/token",
   "device_authorization_endpoint":"https://dev-50h8ivwoimbp1mma.us.auth0.com/oauth/device/code",
   "userinfo_endpoint":"https://dev-50h8ivwoimbp1mma.us.auth0.com/userinfo",
   "mfa_challenge_endpoint":"https://dev-50h8ivwoimbp1mma.us.auth0.com/mfa/challenge",
   "jwks_uri":"https://dev-50h8ivwoimbp1mma.us.auth0.com/.well-known/jwks.json",
   "registration_endpoint":"https://dev-50h8ivwoimbp1mma.us.auth0.com/oidc/register",
   "revocation_endpoint":"https://dev-50h8ivwoimbp1mma.us.auth0.com/oauth/revoke",
   "scopes_supported":[
      "openid",
      "profile",
      "offline_access",
      "name",
      "given_name",
      "family_name",
      "nickname",
      "email",
      "email_verified",
      "picture",
      "created_at",
      "identities",
      "phone",
      "address"
   ],
   "response_types_supported":[
      "code",
      "token",
      "id_token",
      "code token",
      "code id_token",
      "token id_token",
      "code token id_token"
   ],
   "code_challenge_methods_supported":[
      "S256",
      "plain"
   ],
   "response_modes_supported":[
      "query",
      "fragment",
      "form_post"
   ],
   "subject_types_supported":[
      "public"
   ],
   "id_token_signing_alg_values_supported":[
      "HS256",
      "RS256"
   ],
   "token_endpoint_auth_methods_supported":[
      "client_secret_basic",
      "client_secret_post"
   ],
   "claims_supported":[
      "aud",
      "auth_time",
      "created_at",
      "email",
      "email_verified",
      "exp",
      "family_name",
      "given_name",
      "iat",
      "identities",
      "iss",
      "name",
      "nickname",
      "phone_number",
      "picture",
      "sub"
   ],
   "request_uri_parameter_supported":false,
   "request_parameter_supported":false
}

Interesting articles related to OIDC discovery:

For more information about refer to the OIDC discovery documentation.

Resources


Jaime González García

Written by Jaime González García , dad, husband, software engineer, ux designer, amateur pixel artist, tinkerer and master of the arcane arts. You can also find him on Twitter jabbering about random stuff.Jaime González García