A participant has identified a provider and is about to initiate a conversation on behalf of a user.
How can a participant engage in a conversation on behalf of a user?
- Many services are personalized and thus require a user identity to provide the service. A generic application or service needs to pass the user's identity to this service provider.
- Users should only authenticate directly to a service and not share their credentials, such as user ID and password, with another participant.
- Services should not store user credentials as it may present a security risk.
- Prompting a user with every request or session to the service is inconvenient and not possible for background processes that execute without the user's immediate attention.
Have the consumer request an access token from the service provider based on the consumer's identifier and the user authenticating the request to the provider. The consumer subsequently passes this token with the request to the provider.
The User Grants Access conversation involves the following participants:
- The Consumer
- The User (or Resource Owner)
- The Provider
Example: OAuth
IETF RFC5849 specifies the following steps:
- The client obtains a set of temporary credentials from the server (in the form of an identifier and shared-secret). The temporary credentials are used to identify the access request throughout the authorization process.
- The resource owner authorizes the server to grant the client's access request (identified by the temporary credentials).
- The client uses the temporary credentials to request a set of token credentials from the server, which will enable it to access the resource owner's protected resources