IBM Cloud authentication and authorization rely on OAuth 2.0, an industry-standard protocol. More information about OAuth 2.0 can be found in RFC 6749, which covers the OAuth 2.0 Authorization Framework. IBM has extended some functionality of OAuth 2.0 to meet the specific requirements of IBM Cloud and its customers.
When applications authenticate and obtain permissions, they receive an access token as specified in RFC 6749. In IBM Cloud, the access token not only represents the authenticated identity and its permissions but also the currently selected account. When applications make API calls to IBM Cloud Services, the access token is included in the HTTP authorization header to provide caller information. The target IBM Cloud Service then makes authorization decisions based on the content of the access token.
For certain use cases, applications can also retrieve refresh tokens from IBM Cloud Identity and Access Management (IAM). Refresh tokens allow applications to obtain a new access token when the previous one expires. This is particularly important for the IBM Cloud Console and IBM Cloud CLI, as it allows users to continue using these services without having to log in again after the access token expires. Refresh tokens need to be securely stored and eventually expire.
There are two ways for customer applications in IBM Cloud to create an access token for invoking IBM Cloud services. The first method involves using an API key to obtain an access token. The second method is used when running on an IBM Cloud-managed compute platform. In both cases, the application has access to the necessary credentials, so there is no need to store and use refresh tokens. When a new access token is required, the application can use the API key or compute resource token again.
Access tokens in IBM Cloud use the JSON Web Token format (JWT) to ensure scalability. These tokens are signed using the RS256 asymmetric algorithm, allowing any IBM Cloud service or third-party application to verify the token’s signature using the public part of the signature key. IBM Cloud IAM provides the public signature keys for validation. By caching these keys for one hour, services and APIs can validate tokens without the need to call IAM for each token, leading to improved scalability. However, since access tokens cannot be revoked, each adopter would need to check the token’s validity with IAM in the event of a revocation, which could be detrimental to performance.
Refresh tokens, on the other hand, do not follow a specific format and can only be created and understood by IBM Cloud IAM. To obtain a new access token using a refresh token, the refresh token needs to be sent to IAM for validation. If the validation is successful, IAM will create a new access token. However, if the related user or service ID does not exist anymore, the refresh token will fail to create a new access token.
A login session is created when an end user logs in to the IBM Cloud Console or IBM Cloud CLI. Users can manage their login sessions, including ending specific sessions or viewing an overview of all sessions. A login session can end in several ways, such as expiration, inactivity, manual logout, or exceeding the maximum number of sessions. The parameters for login sessions, such as maximum lifetime and inactivity timeout, can be configured by the IAM Administrator.
Login sessions in IBM Cloud combine the security of OAuth 2.0 with session management capabilities. When a user logs in, the calling application receives an access token and refresh token from IAM. IAM starts a login session and associates the tokens with the session. Access tokens have a limited lifetime of 20 minutes or less, and when they expire, the refresh token is used to obtain a new access token. The session also has an inactivity timer that is reset with each activity. The session ends if it is revoked, expires, or detects inactivity.
Creating and persisting login sessions is a resource-intensive operation, so IBM Cloud does not create a login session for every token. Tokens without login sessions can still be used to access IBM Cloud services and APIs, and their behavior is controlled by separate configuration settings.
In summary, IBM Cloud authentication and authorization rely on OAuth 2.0, with extended functionality to meet IBM Cloud requirements. Access tokens represent authenticated identities and are transmitted as part of API calls. Refresh tokens can be used to obtain new access tokens. Access tokens use the JSON Web Token format and can be validated using public signature keys. Login sessions combine OAuth 2.0 security with session management capabilities. Tokens without login sessions can still be used to access IBM Cloud services.
Source link
