DMZ converts client_credential to password

[Tattwadarsi Biswal]

Requirement : Generate auth token(grant_type=password) after registration within gateway(DMZ)

Step-1 : Client call guest token service: To get guest(scope) token [grant_type=client_credentials(/auth/oauth/v2/token)]
Step-2 : Client call registration service to register user
Step-3 : Gateway(DMZ) update/remove guest token and invoke auth(scope) service (grant_type=password) for registration service

 

Planning for below approach, is there any best approach/practice?

 

Approach:
1. Route to auth service (grant_type=password) after user registration with grant_type and resource_owner
2. Delete guest token from otk_db

 

 

[grant_type=client_credentials(/auth/oauth/v2/token)]
{
"resource_owner": "Token 2.0",
"client_key": "1098567432",
"expiration": "1515084452",
"jsessionid": "LNAlWOtodjnXFSWkrJT2KIZ6zeT1oe",
"scope": "guest",
"grant_type": "client_credentials"
}

[grant_type=password(/auth/oauth/v2/token)]
{
"resource_owner": "[e-mail]",
"client_key": "1098567432",
"expiration": "1515085168",
"jsessionid": "GJslY1d00B8dbqRV7yYoIjqt",
"scope": "auth",
"grant_type": "password"
}

[saspr02]

H ello!

You could use your client with "client_credentials" flow to retrieve a token with a scope such as "register_user". You would have the user fill out details in a form and have the client call an endpoint such as /registeruser including the given details. That endpoint would require an access_token issued to scope=require_user. At the same time you could configure "OTK Require OAuth 2.0 Token" to mark the token as "one time use only" so that it would be deleted. Once successfully registered you client would go through the password flow.

 

In general I think this is more a business requirement (how to on-bord users) and not so much a technical question. How to design the flow is more or less up to you.

 

This is just a first high level thought but I hope this helps!