Users login to a mobile application and the API service(A) issues an access token. But mobile apps have a WebView and an external site opens inside(API service(B)). That requires a different access token. So the flow is this.
When a user accesses an external site(inside the mobile app) a call is made to the API service. A
The API service A calls API service B in the backend with a password grant flow with client ID and secret.
Access token is issued by API service B. API service A sends it to the mobile app
The point I want to confirm is this. All Mobile app users that need the access token from API service B have to be registered with API service B. This has to be done somehow in the backend for this flow to work.
I am not sure I follow. API services don’t mint access tokens, rather they consume them. Authorization servers mint access tokens.
There is an authorization flow ‘on behalf off’ where the token minted from authorization server A, can be used to obtain a token from authorization server B that impersonates another user. Not sure if this is what you want? However Okta does not yet support this flow.
The other thought might be your mobile application calls API service A with an access token it received from an authorization server (Okta?). API service A then does a Resource Owner Password Grant flow into another authorization server (Okta or other) to get a new access token which API service A then returns to the mobile client.
However authorization servers mint tokens where API resources consume them.
The other thought might be your mobile application calls API service A with an access token it received from an authorization server (Okta?). API service A then does a Resource Owner Password Grant flow into another authorization server (Okta or other) to get a new access token which API service A then returns to the mobile client.
Yes. Authorization server A issues an access token. Not okta at this point. This token is passed back to API A by the device. API A stores a client_id and client_secret in the DB which it uses to get another access token from Authorization server B. This access token from B is passed back to the mobile. Device sends it directly over the internet to view a website inside the mobile. At this point these two access tokens are not related at all.
Authorization server B accepts ‘grant_type’ = password without a password because Authorization server A has authorized the device. So Authorization server B needs ‘grant_type’ = password, client ID, client Secret and the User ID from Authorization server A’s access token.
Authorization server B trusts the user ID in Authorization server A’s access token.