Introduction to IAM

Identity and Access Management (IAM) systems ensure user identification and access to functionality and data in applications. IAM is a term that has long been used for an individual organization’s need to ensure that the right people have access to the right parts of the internal digital environment. Nowadays, an organization’s digital services extend to customers, suppliers and partners, which results in completely new requirements on IAM such as, to be able to connect and use these organizations’ own ability to identify and ensure access to the digital environment. This is often called Customer Identity and Access Management or shorter CIAM.

Basic Concepts

At the very core of CIAM is of course Identity, which is someone or somewhat that wants to get access to your digital resources, such as web applications, APIs and so on. Often the identity is a user account that represents an end-user such as a customer, an employee, a member and whoever you want to allow access, but the identity could also represent non-humans such as software (another system, robotics, Internet of Things devices).

Authentication is verifying who a user is (determine the identity) and Authorization is verifying what resources they are allowed to access. In CIAM it is also important to determine what organization (tenant) the user belongs too.

Authway by IRM enables many capabilities that your scenario most likely will need some of:

• Smooth sign-in experience: A professional sign-in that works on all devices, with your brand’s look and feel.
• Easy sign-up: The best sign-up is the one you don’t need to do at all and we support full provisioning of users from their enterprise identity providers, but for private individuals the sign-up is just as easy as the sign-in.
• Multi-factor authentication (MFA): With many users’ credentials stolen it is more important than ever to require additional proof of identity.
• Re-authentication: Require the user to authenticate once more before allowing them to perform sensitive operations.
• Step-up authentication: Require a user to use a stronger proof of identity, such as a legal identity provider, for certain operations.
• Role-based access control (RBAC): Create groups of users to ease the management of access privileges.
• Attribute-based access control (ABAC): When supporting many different organizations need for control of access privileges it will fast become impractical to create a RBAC model that fits all. Instead it is better to verify access to functionalities and additional attributes like the organization (tenant) that the user belongs too.
• Impersonate: Provide better customer support experience with the possibility to run your services as if you were the user.

Authentication and Authorization

Authentication is the process of verifying the user, but the challenge when doing this for customers, suppliers, partners and other organizations is that each organization has their existing infrastructure of doing that already. Instead of forcing the user’s of these organizations to create new identities it is more secure and convenient for them to re-use the identity they already have.

Authway by IRM supports many Identity Providers

• Local username and password
• Social identity providers, such as Google, Twitter, Microsoft and many more
• One-time passwords (OTP)
• Legal identity providers, such as Swedish BankId, Freja or other
• Enterprise providers, such as Microsoft Active Directory (on-prem or Azure)

The Identity providers can be enabled or disabled per tenant and it is even possible to add custom OIDC or SAML identity providers for a tenant.

Authorization is the process of determine what resources the identified user is allowed to access and there are many aspects of this. Some of this aspects is handled fully or partial handled by Authway, but there is always a responsibility on your applications to apply the logic and make the final call about what a user can access and not. Authway helps you with authorization by:

• Control which organization (tenant) is allowed to use which modules. This allows you to split your systems into parts that different organizations should be allowed to use without you needing to do anything.
• Configure build-in groups that will be created for each organization allowing you to use role-based access control (RBAC).
• Configure functionalities that your system needs to verify access too and allowing the organizations to configure access to the functionalities in a way that fits their own organization without you needing to figure out a one-size fits all access control model.
• It is even possible to limit access to a functionality to specific organizations (tenants), for example if you have created a custom report for a specific customer.
• Makes it easy to filter information based on which organization (tenant) a user belongs too.
• Determine how the user have signed in and require them to use a stronger identification for sensitive operations.
• Require a user to re-authenticate before performing a sensitive operation.

Introduction to OIDC and OAuth

OAuth 2.0

OAuth 2.0 is a protocol used to access HTTP resources (API:s) on behalf of the user (resource owner) without sharing the user’s credentials. It’s the most commonly used standard for IAM today and used by large social media platforms as Facebook, Google and Twitter.

OpenID Connect

OpenID Connect (OIDC) is an identity layer on top of OAuth 2.0 that makes it easy to verify a user’s identity and retrieve basic information about the user from the identity provider. This allows applications to verify the identity of the end-user and retrieve this information as JSON web tokens (JWTs) using one of the grant types confirming to the OAuth 2.0 specification.

OAuth Grant Types and How to Choose?

The OAuth 2.0 protocol defines different grant types for obtaining access tokens:

• Authorization Code (section 4.1)
• Authorization Code with PKCE
• Client Credentials (section 4.4)
• Device Code
• Refresh Token (section 1.5)
• Implicit (section 4.2) (legacy so not recommended)
• Resource Owner Credentials (section 4.3) (legacy so not recommended)

Authway by IRM have support for all, except for Device Code (typically used on devices like televisions). Since we don’t support Device Code and both Implicit and Resource Owner Credentials are not recommended the choice is between Authorization Code or Client Credentials. To choose between these two the only question you need to answer is if it is an end-user that is signing in or if it is a system-to-system use case? For system-to-system access you should use Client Credentials and for end-user scenarios you should use Authorization Code, preferably with PKCE since it is more secure.

Explaining the Grant Types

Before explaining the grant types, let’s take a look at the different OAuth roles.

• Resource Owner: Entity that can grant access to a protected resource. Typically, this is the end-user (User).
• Resource Server: Server hosting the protected resources. This is the API you want to access.
• Client: Application requesting access to a protected resource on behalf of the Resource Owner.
• Authorization Server: Server that authenticates the Resource Owner and issues access tokens after getting proper authorization.

Client Credentials

The Client Credentials grant type is the simplest of all and it uses a client_id and client_secret credentials of a Client to authorize and access protected data from a Resource Server.

1. The client application makes a token request to the authorization server by providing the client credentials.
2. The authorization server authenticates the client and issues an access token.
3. The client application uses the access token when requesting resources from the resource server.

External systems

A challenge for a resource server that wants to support both system-to-system and end-user access tokens is that the contained claims in the tokens will be very different. For an end-user you’ll have claims for name, email, tid (tenant id), role and perm (permission), but a system-to-system access token will only have claims like client_id and client_name. This can be cumbersome to handle when validating access permissions and logging for example who have changed in data.

To make it easier for a resource server Authway have a concept called External system. An external system is a combination of a configured client and an user. Authway also overrides the standard token creation so that the token will include claims like name, tid and perm even in the Client Credentials grant.

Authorization Code (with PKCE)

The Authroization Code grant type is the most commonly used grant type to authorize the client and user access to protected data from a resource server. This uses browser redirections for communication and it provides some important security benefits such as the ability to do the authentication without the access token passing through the user-agent and potentially exposing it to others. This grant type can be used for SPA and native applications too, but in these scenarios it is usually with the access token in the user-agent. For SPA this can be avoided by creating a backend for frontend to increase the security.

1. Resource owner tries to access the client application via his user agent.
2. The client application makes an authorization request to the authorization server.
3. The authorization server authenticates the resource owner.
4. Authorization server sends a temporary Authentication Code back to the client.
5. The client application makes a token request to authorization server with the authorization code.
6. If the token request is valid, the authorization server returns the access token, expiration time and a refresh token (if requested).
7. Finally, the client application uses the access token when requesting resources from the resource server.

Refresh Token

The Refresh Token grant is used by clients to exchange a refresh token for an access token when the access token has expired. When an access token is obtained using authorization code grant type or client credentials grant type, to give additional security it has been designed to expire after the given token expiration time. In this case without end users interaction, authorization server will validate the refresh token and issue a new access token.

Glossary

A

Access Token

An Access Token is a piece of data that represents the authorization to access resources on behalf of the end-user. The access token is typically in the form of a JSON web token (JWT).

Authorization Server

Server that authenticates the Resource Owner and issues access tokens after getting proper authorization.

Auto-linking

The process of automatically associate an external identity provider with a user, which can be used to associate more than one identity provider with an user account and/or to remove the need to send an invitation to a user.

Auto-provision

The process of automatically create a user based on information from an external identity provider, which remove the need for any manual administration of users.

C

Claim

A statement (for example a name or an email address) about an entity (typically the user). Here is a list of supported claims.

Client

Application requesting access to a protected resource on behalf of the Resource Owner.

I

Identity Provider or Identity Server

Server that identifies an entity (typically the user) and issues token after proper authentication.

J

JSON web token (JWT)

JWTs contain claims (for example a name) about an entity (typically the user) plus some extra metadata.

L

Linked users

Linked users are users in different tenants where all of them will get the same sub claim (unique identifier).

O

OAuth 2.0

OAuth 2.0 is a protocol used to access HTTP resources (API:s) on behalf of the user (resource owner) without sharing the user’s credentials.

OpenID Connect

OpenID Connect (OIDC) is an identity layer on top of OAuth 2.0 that makes it easy to verify a user’s identity and retrieve basic information about the user from the identity provider.

R

Resource Owner

Entity that can grant access to a protected resource. Typically, this is the end-user (User).

Resource Server

Server hosting the protected resources. This is the API you want to access.

T

Tenant

The (mother) organization that a user belongs too.