AS-centric AS - seamless migration

Care has been taken to ensure that both the client-centric and the AS-centric implementation of the authorization server are compatible with each other.

• Both authorization servers can be run on the same Airlock IAM in parallel
• The client decides which authorization server will be used by choosing the correct endpoint URLs

The following timeline shows how a migration from the current client-centric implementation of OAuth 2.0 and OIDC to the new AS-centric deployment can be achieved without impact for end users.

To profit from a seamless migration, the existing client-centric AS remains unchanged and continues to serve all users that still use the current version of the different client applications. The client-centric AS will only be removed from productive operations, once all users have upgraded their clients.

The new AS-centric AS can be deployed and tested without any impact on end users. As long as the new client versions are not made available to users, the AS-centric AS can be tested (testing period).

With the start of the deployment of the new client version to users, the testing period ends and the migration period starts. The moment a user decides to upgrade the client application from the current to the new version the switch from the client-centric AS to the AS-centric will be made as well.

The duration of the migration period mostly depends on the speed of how quickly users will migrate to the new version of the client.

When migrating from a client-centric to an AS-centric setup the following steps should be implemented to allow for a seamless migration as outlined in the previous chapter.

1. The configuration of the client-centric authorization server remains unchanged during the entire migration period. It continues to serve all the not yet migrated clients.
2. Configure the new AS-centric authorization server with
1. the same issuer as the client-centric authorization server
2. static client that is identical to the client of the client-centric AS (with identical credentials)
3. Enable the Migration of client-centric tokens
1. This ensures that the AS-centric AS will accept client-centric refresh tokens and return AS-centric access and refresh tokens
2. This is configured in the Advanced Settings of the authorization server (Migrate Client-centric Tokens)
4. Deploy clients that use the new AS-centric authorization server to end-users

In this setup users with old tokens will be able to continue to use these tokens.

Users that use an updated version of the client for the first time will see the following behavior: providing an old access token, regardless of its validity, will be answered by the server with an error (typically 401 - unauthorized). A well-behaved client will use the refresh token to obtain a new set of tokens. If the refresh token is valid for the old client-centric AS, this will be successful and a new set of refresh and access token will be returned to the client. The migration from the old to the new authorization server is complete. All future requests to the authorization server will be conducted with new tokens.

To complete the migration functionality, the token revocation endpoint of the AS-centric authorization server is able to handle both client-centric and AS-centric token revocation requests.

It is only possible to upgrade tokens from a client-centric to an AS-centric authorization server. It is never possible to downgrade tokens.

Once the migration is complete, all client-centric tokens are revoked and can no longer be used.