We have 2 okta instance(X and Y). In Y we have users created. We created IdP(openID connect IdP) in X which has clientId and client_secret of app in Y. We want to perform authentication with the help Y account. When we try it in UI based on domain rule it correctly redirect us to Y instance URL to sign in and it get authenticated. But when we give user_id password and call sign in our backend code calling “api/v1/authn” with host of okta instance x, it does not validate User. How can we resolve this issue?
You need to call
/authorize endpoint with correct
idp value in it. That will cause authentication against your Y
Thanks for the reply. I will check on this approach. But currently there are many places is backend which are making call to api/v1/authn so I was thinking is there any way we can have desired effect without changing code. Something like inline hooks concept or setting in Okta Dashboard something like that. Is it possible in any such way?
I’m sorry, I don’t know if it’s possible. But let’s see what Okta’s stuff have to offer
You can’t use an IdP as a source for pass-through authentication with /api/v1/authn because directory providers are designed to work with redirection in the browser and are used for social media providers and can be used with a generic OpenID Connect provider as well. Which explains why your UI test works, but your back-end API call doesn’t. When the API call is made, there isn’t any way to prompt the user for authentication and to prompt to grant access to information in the remote profile.
What you need is a “directory integration” found under the Directory tab in the admin UI. Normally you would connect to an Active Directory or LDAP source, but you can connect to another Okta org using LDAP. This is not an official scenario, but I have tested it and it does work. This is a modified way to handle an LDAP directory integration, so I’m not going to repeat the instructions you can find Get started with LDAP integration | Okta, but I’ll give the flow and the information you need for this scenario:
- In Y, go to Directory → Directory Integrations. Pull down the Add Directory button and select LDAP Interface. This is a little weird, because while the other two choices allow you to set up a connection, this choice enables the LDAP interface for your Okta Org! Note the settings that appear. Now Y will serve LDAP for X.
- You have to use an LDAP agent, and since this cannot run on the Okta tenant you’ll have to run it on one of your own servers (Windows or Linux). The agent phones home, so it doesn’t have to be on an exposed server, just one with outbound Internet. On the computer where you will run the agent log into the admin UI for X, instead of creating the App, go to Directory → Directory Integrations and create a new LDAP Directory (the other choice). Download and install the Agent, and you will be able to go to the next step:
- You’ll have to manually configure the mappings in Step 2, these are the required fields you need:
b. Distinguished Name (DN): cn
c. Unique Identifier Attribute: uniqueIdentifier
d. User Object Class: inetOrgPerson
e. User Search Base: ou=users, dc=, dc=<okta,oktapreview,etc.>, dc=com
e. Account Disabled Attribute: organizationalStatus
f. Account Disabled Value: SUSPENDED
g. Group Object Class: groupofUniqueNames
g. Member Attribute: uniqueMember
e. Group Search Base: ou=groups, dc=, dc=<okta,oktapreview,etc.>, dc=com
f. Pick “email” for the user id type
g. Enter a fully qualified username on Y that exists for the verification step.
- Now if your back end hits api/v1/authn at X with a user at Y it will work. You can check this with Postman too by calling the API endpoint at X with the user name and password.
Good luck, post back and let me know how it works out for you!