Hi, we currently have a SPA + .net 4.8 WebApi
The SPA prompts for user and password and get an access token from the Webapi if the password is ok in our DB.
Then the SPA calls any webapi endpoint with the provided access token (this token contains some specific claims to our app like internal user code, language, etc)
We are now required to implement OKTA SSO for some of our customers (is a saas webapp, other customers will continue to get tokens with our authz server).
We’ve sucessfuly implemented the interactionCode flow with the signIn Widget, and we are able to get the Okta access and Id tokens from showSignInToGetTokens method …
QUESTIONs:
Is it ok to use the interactiocode flow in this scenario?
What do we need to do with the okta accestoken?
-We thought about sending okta access token to be validated server side (check if the signature matches)
-And if it is valid, then if the subject contained in the accesstoken is registered in our application, then we generate our accessToken (with our custom claims etc)
-Then the SPA will use our generated accessToken to consume the webapi
Hello,
My Suggestion would be to reach out to Okta Support or Sales to inquire about speaking with the professional services team. They have a wealth of experience in system design and would be the best resource for this discussion.
If this is not an option a suggestion would be if you want to mimic the current flow you have today perhaps the following:
Instead of having the SPA application do the flow to the Okta Org(s), do an authorization code flow from your web api/server.
This way the client could be redirected to their Okta tenant where the user is familiar with the login screen.
Authenticate with any MFA if needed.
Redirect back to your web api/server where your server would exchange the code for Okta tokens.
Your server could do whatever validation is required and then mint it’s own tokens as it does today.
Again, speaking with the Okta PS team would be the best option.
hi @bmat, for me it was impossible to reach PS team… no answers…
I saw your question, and we are having the same problem to solve.
What I thought as a workaround is the following
Integrate the signIn widget in the SPA (for this customer disable old login view)
Call the widget method showSignInToGetTokens
That method, when the user enter his credentials into Okta login form, will return an accessToken
With that (okta)accesToken I will extract the username from the claims in the client
I will send a request to my API method /token with the username and as password the whole (okta) accessToken
With that info in the API, I will check first the validity of the accessToken ( Validate Acces Tokens )
If the token is invalid → error
If the token is valid, will compare the user inside the claims with the one sent to /token
After all validation passes, will check if the user name is valid in our DB (if it is still active, if it has okta login enabled, etc)
After that, will mint our accessToken (the same accessToken as if the user would have login with usr+pwd)
Then the angularjs SPA will use that accessToken (granted from our API) to call the protected API methods
This is an approach we are evaluating, dont know if is the right way to do, also we need to analyze how the refreshtoken will work ( if the API needs to refresh our custom accesToken or if we have to call the widget to refresh the okta accessToken and refresh with that…)
