Hello. I’m trying to create SSO integration for my simple web app.
I took the self-hosted example for ASP.NET from Okta github.
I’ve read the Okta’s guide “Build a SSO integration”, but I still can’t get work a simple scenario when user clicks my app’s icon inside Okta dashboard and getting automatically signed-in.
The guide tells me “6. Enter or change the URI used to initiate the sign-in request.” and also the description of that field in the Okta’s app settings form tells me that “When Okta redirects to this endpoint, the client is triggered to send an authorize request”.
But the question is - what does it mean? I mean the whole guide+example does not work without this particular detail about sending that authorize request.
Seems I need to go through all the API and OAuth/OIDC references to make a simplest thing that Okta’s dashboard is made for. It’s a bit confusing…
Thanks for the response.
No, it’s not what I need and of course I’ve updated config as the first step.
Actually all what I needed is to copy the code from Login (POST) action but remove sessionToken from the AuthenticationProperties and then set “URI used to initiate the sign-in request” to this new action (let’s call it LoginViaOkta). - after that I got the auto-login on okta’s dashboard icon click.
Still I have some questions left:
Why do I mandatory need to set grant type to implicity (hybrid) to make my app able to be added as an icon to the okta dashboard. Isn’t implicit (hybrid) flow expose id token to the user-agent that seems less secure than pure code grant?
On icon click I got the iss query parameter from okta with my okta sever domain (iss for issuer i guess). So I suppose that when i’ve publish my app to OIN i’ll get that okta domain of okta org who have added my app and now their user click’s on my app icon. Hence I guess I need to use that iss parameter as org identifier somehow so to be authorized against right org.
But I tried to set idp parameter for /authorize request but not sure it impacts anything 'cause auto-login wokred for me even with incorrect idp param or even without it.
So how do I use that iss query parameter i got on okta dashboard icon click?
Hello,
Glad you got the first part working. I was going to suggest that you could modify your home page, say
public IActionResult Index()
{
return View();
}
to,
public IActionResult Index()
{
string iss = HttpContext.Request.Query["iss"].ToString();
if (iss != null && iss != "")
{
HttpContext.Request.QueryString = new Microsoft.AspNetCore.Http.QueryString();
return Challenge(OktaDefaults.MvcAuthenticationScheme);
}
else
{
return View();
}
}
For the implicit grant, the reason is that for Okta initiated you have a choice of OIDC Compliant and Okta Simplified. Simplified being similar to an implicit grant where tokens are sent directly. I will look into this more to see if there is a reason why it needs to be enabled for OIDC Compliant.
Not sure I fully understand what you are trying. The issuer parameter (iss) specifies the Okta Org this request came from. So when your application does an /authorize call it would need to use this URL to make the call to. The IdP parameter of an /authorize call is different, it defines which IdP of a specific Org to use to authenticate the user. So if your application has more then one Okta Org using it, you won’t make the /authorize call to the same Org each time specifying IdP as the iss parameter that came in with the request. Rather you will make the /authorize call to that iss URL.
Ok thank you! 'cause it’s strange why can’t we have OIDC compliance using standard code grant flow only.
ok I thought the same actually but iss value that came from okta is just an org’s domain. So I guess I need to construct a new baseurl before /authorize part to make an authorize request to the address that’s in iss param.
And if so then how do I do that 'cause base URLs are constructed basing on OktaDomain middleware setting and I suppose I can’t change it for each request.
Long story short - do I need to do extra work in my app to get SSO enabled for many orgs after publish in OIN and how do I test this 'cause I can’t create another okta org and share my non-published app between these in order to check how it works for several orgs.
Yes, if your application will be destined for the OIN you would not use our SDKs, see here.
For OIN integration each client that installs your application would also go through a process where they provide you details of the client_id/secret for their application. Your application would then need to store this information and either use the ‘iss’ parameter to look it up, or you might use a different subdomain name per tenant, see here.
Sorry but what do you mean? I went through all of these guides and examples only to throw away your SDK and implement the client part of OAuth by myself? I don’t understand… And why it’s only a little remark in Best practices section while’ it’s actually a significant restriction for me - to not use your SDK.
And your link actually leads to “OINC And the OIN: Developer primer” → that in turn contains “Protocol-level requirements” → that in turn refers to “Implement authorization by grant type” which again leads me to Okta SDKs for helping me to implement auth flow… So i dont’ understand, sorry
What do you mean they provide me client_id/secret? Isn’t this a secret info?
And what is “their application”?
I’ve ready about multy-tenancy but still don’t understand how all of it should work 'cause Okta just has not consisting guides for OIN integration nor any working example (from those that I could find via Okta site). And as for multy-tenancy - it’s also not clear what to do with custom auth providers within one org 'cause I only get the org auth server address but they could have many custom auth server addresses within their org isn’t it? I’m talking only about OIN context
Thanks in advance!
Unfortunately with the SDKs as of now there are 2 potential issues that I know of when using them for OIN Applications:
Not all of the SDKs support multi-tenancy
Some of the SDKs will try to validate access tokens returned to them, which can’t be done with the Org Authorization Server.
Each Okta Org that will use your application will need to install it from the OIN. This will basically install a OIDC web application in their Org and will generate a unique client id/secret. This information would then be supplied to your application. When a client from this Org tries to login to your application either by clicking the icon from their Org sending a GET request to your App with the iss param, or using a custom subdomain, your application would need to generate the /authorize request back to their Org. The request would return with a code value your app would exchange for tokens. The call to their Orgs /token endpoint will require the client id+secret b64 encoded as an Authorization header. You also need the client id for the /authorize request.
Currently OIN Application only allow the use of the Org Authorization Server (AS). Clients do not have the option to use a custom AS. This is because many Orgs do not have the API Access Management license needed for custom AS. This is also the reason OIN applications currently can not use the access token, only the id token. Org AS do not publish the key used to sign the access token it mints.
Thank you for explanations.
So for now you just have no SDK that can help somehow with OIN right? I only can use your REST API if I make integration for OIN?
Also wanted to ask what about IDX SDK (Identity Engine) - does it work for OIN? And what does it mean the disclaimer on IDX’s github that it’s only available for selected customers? Can I use it in prod or it’s in kinda beta stage or maby something with commercial license?
Org AS do not publish the key used to sign the access token it mints.
Basically I dont’ need the access token - I need only user identity info (id token).
So I should use /introspect to validate access tokens and somehow implement id_token verification and key rotation and other things by myself locally? Is any example or consistent guide for integrate with exactly OIN support?