Authorization flows
- Actors :
- The client (and also the one that receives the credentials from the user)
- The IDP or identity provider
- HxDR
There are two supported scenarios:
- When your Client is consuming HxDR APIs on behalf of a human user, you will ask HxDR to setup a so called Authorization Code Flow. At the beginning of such a flow the user is directed to interact with HxDR to authenticate (e.g. a web form where they will enter their credentials). At the end of the flow, the Client will receive the tokens. From that moment, and during the validity period of the tokens, the Client will be entitled to act on behalf of that user.
- When your Client is invoking HxDR APIs autonomously, without user interaction, you will ask HxDR to set a Client Credentials Flow. This is for machine to machine communication; you Client is able to authenticate by itself, and receives a tokens in exchange. An example of this case is when your services need to run periodic nightly jobs against HxDR APIs. Or when fetching data on behalf of your system, not of a specific user.
Once a token (bearer + jwt) is delivered to HxDR via the authorization header, HxDR platform identifies correctly the user account and allows user to perform operations according to the access control list of the user.
Choosing the best flow (among the ones that are promoted by the OAuth 2.0 standard) is left to the client, the only thing that HxDR needs to know is if the flow chosen has a need of a client ID and client secret combo or not.
Which OAuth 2.0 flow should I use ? (opens in a new tab)
Understanding Amazon Cognito user pool OAuth 2.0 grants. (opens in a new tab)
Some flows are not meant to be used by third clients like for example: