When the oauth callback endpoint is called, the “exchange code” function is again using the hard-coded issuer which is my app’s original Okta organization. Which I’m okay with here, since we are passing the client id/secret. However, will it know which organization the user is actually signing on to and would it return it in the claims properly? samples-golang/main.go at c7a168ec4d1eac295bf8325f9577ab0de133b72b · okta/samples-golang · GitHub
Given the confusion above, is there a way for me to test multiple organizations using my app before officially submitting my app to OIN? I’d like to make sure that my backend code can correctly handle distinguishing organizations before going to production.
I don’t think the Okta sample app is designed for your specific use case. I remember reading in their docs that they don’t recommend using the SDKs for OIN submissions.
Due to the OIN restrictions of using an org authorization server and the authorization code flow, the SDKs provided by Okta should not be used for app integration development, since they cannot validate the access tokens.
My attempt at answering your questions:
Yes, for an OIN app your app needs to be able to handle multiple orgs/clients. For the sample, they’re assuming there’s only one client/org.
For an OIN app, you will probably need to ask the user what Okta org they belong to. If you offer your customers dedicated subdomains, then maybe you will already know which Okta org the user should be authenticated against. Again, the sample app is assuming there’s only one client/org here.
Good question. I’m not too sure but I imagine there should be a testing process after the app is submitted. Maybe someone else can chip in here.
All I am trying to do is implement a simple OAuth flow where if I can check what organization a user belongs to, and if I have this organization registered in my database, then I can authorize them to use my app and show them the correct resources for said organization.
I am:
An application with one domain name (no sub domains)
I’d like to implement an Okta integration so that various companies could use my application without having to manage users.
I was able to successfully implement OAuth with Okta, but I cannot find any documentation about what my backend should do to manage multiple organizations.
I believe Okta will be the one in charge of creating the client id/secret for every org. (client credentials are created when you create new app). You will need a way for your customer to provide those credentials to you and possibly store them.
This is how I imagine the login process would look like if you are able to store the customer’s client credentials:
On the app login page the user can choose to either authenticate using username/password or SSO (button). The user clicks on the SSO button and your app would prompt them to enter a value that you can use to identify them as one of your customers. Your app would then lookup the client credentials and issuer associated with that unique value.
I’m not sure clients want to give their credentials over. Is this the standard way of doing SSO with Okta? I can’t find any documentation that mentions an app should be storing different organizations’ client id/secrets. Thanks!
It sounds like Okta uses the authorization code flow so you definitely need the client secret to make a /token request to retrieve tokens.
For OIDC applications destined for the OIN, Okta recommends building a “web” application with a dedicated server-side back end that is capable of securely storing a Client Secret and exchanging information with an authorization server through trusted back-channel connections.