Implementing Client credential flow

Questions OAuth/OIDC
1

I want to implement client credential flow, so below steps I have taken

  1. created an application using sign in Method - API Services
  2. Created a custom authorization server, created custom scope, created a access policy and added rule to that access policy

I want to know is it required to create access policies and custom scope in case of creating custom authorization server,
Is there any other way to implement machine to machine flow ? or I am following the correct steps ?

And how these 2 are different Implement OAuth for Okta with a service app | Okta Developer and Implement authorization by grant type | Okta Developer

2

Hello,

When creating a new custom authorization server by default it will not contain any policies/rules, therefore no applications in Okta will be able to make use of it.
The preconfigured scopes for a new Okta Authorization Server assume there is a user context associated with the flow which will not be the case with Client Credentials (machie-to-machine). In most cases API services that accept tokens minted with a Client Credentials flow would be expecting custom scope(s) of some type that dictate the access that token has for the service.

  • OAuth for Okta is using OAuth (Client Credentials or Authorization flow) in order to call Okta API endpoints with a bearer token instead of using an API Token.
  • The Client Credentials flow (using a custom authorization server) is intended to mint tokens that can be consumed by your own API Services.

Thank You,

1 Like
3

Thanks @erik.

I have one more question is there a way i can have admin id or user in token who created the application in client_credential flow or I can find out token is coming from which flow authorization code or machine to machine flow.
The reason for asking this is in my application side permissions are tightly coupled with user.

4

The access_token minted for any application will have a default sub claim mapping of:

(appuser != null) ? appuser.userName : app.clientId

So if there is a user context associated with the flow (authorization code) then there username would be used for the sub claim. If there is no user context associated with the flow (client credentials) then the application id of the application in Okta will be used for the sub claim.

Within your authorization server you could create a custom claim that is only used for your client credentials application and hard code a username or id.
But there is no actual user context associated with this flow.

Thank You,

2 Likes
5

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.