Skip to main content

Identity provider abstraction

Background​

An identity provider (IdP) is a system that manages and authenticates user identities and provides authorization services to other applications. It stores and manages identity information, allowing users to access multiple applications and services with one set of credentials. Essentially, the IdP serves as a trusted authority that verifies users' identities on behalf of other services. Popular examples of IdPs include Google, Facebook, and Microsoft, which allow users to log into various third-party services using their respective accounts.

Various solutions require different types of IdPs. Some systems use their own identity management mechanisms, while others depend on third-party providers. Often, there is a hybrid approach where both private and public IdPs are utilized together.

An IdP is responsible for:

  • Authenticate the end user
  • Manage the end user's identity and password
  • Supply with sign-in mechanism like MFA etc
  • Optionally handle flow for initial registration, password reset, etc

Identity provider authentication token​

Using the IdP token for keeping the end user's access scope is quite common. This is a simple way to get started.
But there are some drawbacks with this approach:

  • The IdP token is not designed to be used for fine-grained access control
    • The scope property is normally very limited
    • You might need to ask an ACL system for access level using the IdP token which makes your system less robust and performant
  • Passing the IdP on each service call could expose personal information
  • The service's must understand the format of the IdP token
    • What happens when you change IdP?
    • What happens when you want to support multiple IdPs?
  • There are more problems when it comes to scalability and flexibility

Akkess approach​

We believe that the IdP should be responsible for identifying the user and managing their identity and password, meanwhile Akkess manage the access control and permissions. This separation of concerns allows for a flexibility and use of multiple IdPs without affecting any of services in a microservice ecosystem.

In this way you can add new IdPs to your solution when needed. The only thing you need to do is to add yet another IdP configuration in Akkess and add support in your frontend application to display proper UI for the added IdP.

Akkess does not replace the need for an identity provider. You would still need to interact with an IdP of your choice and also decide how to handle user registration, password reset, etc.

Akkess IdP integration

End user authentication flow​

When the IdP has authenticated the end user the IdP access token is used to issue an Akkess IAM token. The Akkess token will contain anonymous information about the end user via its actor, its access references, associated tenant and more.

The Akkess IAM token is used when performing calls to services instead of the IdP token. Each service only need to understand one kind of token and can do token validation in one way.

Now we have decoupled the "application token" from the IdP-system and can start taking control of its content and purpose.

Example sign-in flow​

  • Single IdP that is part of the system
  • Tenant is pre-configured

Dynamic sign-in flow with external IdP​

  • Multiple IdPs based on Akkess configuration
  • User choose IdP
  • Tenant is selected by user

Avoid personally identifiable information​

Another benefit of this approach is that the IAM token does not contain any personally identifiable information (PII) or the subject identifier from the identity providers. This shields the end user from its information being spread and also avoid any backend services to trace the identity of the end user.

Google token example with personal information​

const payload = {
  "iss": "accounts.google.com",
  "azp": "938721265975-e5l2657qp3kf67jb4s4o109uc4k8ehkd.apps.googleusercontent.com",
  "aud": "938721265975-e5l2657qp3kf67jb4s4o109uc4k8ehkd.apps.googleusercontent.com",
  "sub": "xxxxxxxxxxxxxxxxxxx", // <= USER ID
  "email": "xxxxxxxs@yyyyyyyy.com", // <= PERSONAL
  "email_verified": true,
  "at_hash": "BJ4NPECMMx9pj09dTTf6vw",
  "name": "zzzzzzzzzzzz", // <= PERSONAL
  "picture": "zzzzzzzzzzzz", // <= PERSONAL
  "given_name": "zzzzzzzzzz", // <= PERSONAL
  "family_name": "zzzzzzzzzz", // <= PERSONAL
  "locale": "sv",
  "iat": 1683870756,
  "exp": 1683874356,
  "jti": "2e192341ef3b0de3f89bdda50c4b0a7cfd035cf6"
}

Akkess token example containing only system generated identities​

const payload = {
  "jti": "cb7da818-e8a4-41a6-b979-a151b5f23de2",
  "iss": "https://api.akkess.io/authorization/v1",
  "acc": "63c65dee83abd41be9f61104",
  "app": "63c65dee83abd41be9f61106",
  "tid": "63c65dee83abd41be9f61108",
  "aud": "63c65dee83abd41be9f61108",
  "sub": "65f2bd99e410a04b36ef3685", // <= USER ID
  "exp": 1683799630,
  "iat": 1683792430,
  "ars": [
    {
      "r": ["STUDENT"],
      "n": ["63d298bd78a47f40d600bd34"]
    }
  ]
}

Identity provider integrations​

Akkess supports IdPs that fulfills the OpenID Connect (OIDC) standard. This means that you can use Google, Facebook or any other IdP that supports OIDC.

Akkess IdP configuration can be made via Akkess IAM Console or via the Authentication API.

The IdP configuration is made on Akkess Application level. Which means that all tenants within same Akkess Application share the same IdP configuration.

Copyright © 2019 Akkess