we are using Okta for our OIDC implementation, we are able to create user when he/she is not available but the problem is, the user id is getting created something weird(may as per the requirement but not suitable for us). Currently it is getting creating something like this, but we need the userid based on his name/email id configured in Okta, how can we do this?
Correct me if I am wrong, Is this an OKTA question? user creation should be ideally handled by OKTA right? And Couchbase should handle the tokens from OIDC which is authenticated by SG?
The Sync Gateway user is based on the subject claim in the token. That is the principal Id. The name and email claims in a JWT are not guaranteed to be unique and hence not used for generating the user Ud. To guarantee uniqueness of the subject claim across issuers, the sync gateway prefixes the same with the issuer Id. If you do not want the issuerId, then you must specify a user_prefix in your config.
So for instance, if your subject is “008artt9xuuFv6FWYzB8x96” and you specify the user_prefix to be “okta:”, then the user would be “okta: 008artt9xuuFv6FWYzB8x96”
Thanks Priya. Is there a way we can add user name? my thinking is wrong but let’s say we have 2 users access to the application in Okta, so what will be the user id in this case. Both users id will be same, because sub is coming from the client_id(Okta configuration)
Sorry I spoke wrongly.
I tired with another user for the same app , the sub value is different in both cases any have is there a way we can make the name to create user. For example,
for the second user I am getting below
“name”: “nagarajan nags”,
“name”: “nagarajan subxxxxx”,
All I am trying to ask is, is there way we can customize it to use Name field? We can make sure it will be unique at Okta Level. Is that possible?
Subject does not come from OIDC config. It is unique for an issuer and is contained in the token. For that reason, it is selected as the unique identifier for a user.
What is the use case for needing to customize the name field ?
Here is our use case. We have a custom micro service which is used do a channel mapping for a requested user in sync GW.
Lets say we have a channels a,b,c available but it has not been mapped anything at sync GW level. Now we a mobile application which will send user information to this micro service and based on some criteria micro service will be creating the channel mapping in sync GW(using sync GW rest Api).
Now the problem is, mobile application only knows the name field, it don’t know the sub value for the user( sub we can extract is from token but we don’t want show that to actual user so we want to keep it at user name level).
Mobile app sends information -> name : nagarajan subxxxxx
Micro service -> receives the name field and do some business logic and gets the channel “a” should be mapped, so it calls sync GW rest api to update the channel information for this nagarajan subxxxx.
I am not clear on what you meany by " showing it to actual user.". The app has the token. You can programmatically extract the subject using a nAuth0 library and send it in the request to the microservice. External users only see the username . This is the typical implementation in implicit flows.
Micro service → receives the name field and do some business logic and gets the channel “a” should be mapped, so it calls sync GW rest api to update the channel information for this nagarajan subxxxx.
What is the business logic that it uses to do the mapping ? Why does the mapping have to be dynamic ? As in, why does it need the mobile app to send user information to do that. Can’t the the micro service can set up this mapping upfront by contacting the identity provider for list of all valid users and when user is authenticated on mobile app, it can update that user via REST endpoint with channel info
That said, have you looked at configuring OKTA to use the email (or whatever identifier you want) as the subject ? That would be the right place to do it as it is the identity provider. The principal is the subject so you must set it to whatever makes sense in the context of the app. Doing this at your identity provider ensures that the identity is the same in OKTA and in our system.