Skip to main content

Authentication / Authorization

All azuma products are backed by azuma doa for Authentication and Authorization;

azuma doa is based on the state-of-the-art, secure, and widely deployed open-source Ory Hydra Federation Server and provides:

  • OAuth 2.0
  • OpenID Connect (OIDC)
  • Access Control List (ACL) based authorization system

to authenticate and authorize users.

OAuth 2.0​

OAuth 2.0 is a standard authorization protocol that enables third-party applications to access a user's resources without requiring the user to share their credentials. It can be implemented for user centric services as well as for secure machine-to-machine communication.

OAuth 2.0 involves four main components:

  1. resource owner: The entity that owns the resources, such as a user.
  2. client: The application that wants to access the resources on behalf of the resource owner.
  3. authorization server: The server that authenticates the resource owner and issues an access token to the client.
  4. resource server: The server that holds the protected resources and accepts the access token to grant access to the client.

OAuth 2.0 works by the client requesting authorization from the resource owner to access their resources.

  • The resource owner grants authorization to the client by redirecting the client to the authorization server.
  • The authorization server authenticates the resource owner and issues an access token to the client.
  • The client then uses access token to access the protected resources on the resource server.

OAuth 2.0 also supports the use of refresh tokens, which enable the client to obtain a new access token without requiring the resource owner to re-authorize the client. This helps to minimize the number of times the resource owner is required to authenticate, making the authentication process more convenient for the user.

OpenID Connect (OIDC)​

OpenlD Connect (OIDC) is an authentication protocol built on top of the OAuth2 framework. It enables clients to verify the identity of end-users based on the authentication performed by an authorization server, as well as obtain basic profile information about the user.

While OAuth 2.0 provides a mechanism for a client application to obtain access to protected resources on behalf of a user, it does not provide a standard way to authenticate the user. OIDC addresses this limitation by introducing an ID Token, which is a JSON Web Token (JWT) that contains information about the user and their authentication status.

  • When a user authenticates with an OIDC provider, the provider issues an ID Token that contains a set of claims about the user, such as their name, email address, and unique identifier.
  • The client application can use this ID Token to authenticate the user and obtain additional information about them from the OIDC provider's userinfo endpoint.

In addition to the ID Token, OIDC also defines a standard set of scopes and endpoints for obtaining additional information about the user, such as their profile and email address. This makes it easier for client applications to obtain the information they need to provide a personalized user experience, while also providing a standardized way to secure and authenticate user information.

note

You can use azuma doa if you want to authenticate your users with their social sign-in accounts from providers like Microsoft or Google, or an existing single sign-on (SSO). It supports login via any OIDC-compliant provider. Learn more in the social sign-in documentation.

Flows​

Currently supported and ready to be used:

  • Authorization Code Flow
  • Authorization Code Flow (with PKCE)
  • Client Credentials Flow

Not yet supported:

  • Device Authorization Flow

Out of scope and will not be supported:

  • Implicit Flow (please use Authorization Code Flow (with PKCE) instead)
  • Resource Owner Password Flow (please use Authorization Code Flow (with PKCE) instead)

Further Information​

For information regarding roles, permissions and scopes please check the azuma doa documentation.