- A Resource Owner is the entity capable of granting access to resources. In our context this is the IMS Platform Authnz service. The Resource Owner issues Access Tokens and Refresh Tokens (see definitions below) that allow OAuth Clients to access Resource Servers on behalf of a user.
- A Resource Server is a service hosting protected resources. In our context this is the other IMS Service APIs, some examples of these are the IMS Admin Service or the IMS zeuz Service.
- An OAuth Client is the application making requests to protected resources.
In our context this could be:
- Web applications, such as the IMS Console
- Command line tools, such as the IMS CLI
- Other services and applications, including IMS products and your own applications and services.
- Access Tokens are short-lived credentials returned by the Resource Owner. These should be attached to requests made to Resource Servers and provide both authentication and authorization for those requests.
- Refresh Tokens are long-lived credentials returned by the Resource Owner. These can be exchanged for new Access Tokens, allowing for OAuth Clients to maintain long term access without requiring additional sign ins from the user.
- An Authorization Code is a one-time credential that can be exchanged for a Refresh Token and Access Token pair. These are issued by the Resource Owner after successful authentication.
- Client Credentials are credentials used to authenticate OAuth Clients, and are required when exchanging a Refresh Token for a new Access Token.
- Scopes are embedded in Access Tokens, and are requested by the OAuth Clients during authorization. Users will be asked to confirm that the OAuth Client should be provided the relevant Scopes.
Access Tokens, Refresh Tokens, Authorization Codes, and Client Credentials are sensitive credentials. They should never be stored or shared in plain text. Access Tokens and Authorization Codes should never be stored at all as they are short-lived credentials intended for use within a single session. Refresh Tokens and Client Credentials are long-lived, and could be stored safely in tools or services like AWS Secrets Manager and HashiCorp Vault.