I am in the process of building a single-page application using Okta for SSO. I am currently using the okta-signin-widget for handling the heavy lifting but I was wondering what the recommendations would be in terms of using OIDC vs the Okta APIs. I have the following scenario for my SSO needs:
Multiple internal single-page applications (can be OIDC or Okta API)
Multiple external applications using SAML 2.0 and OIDC
Is there a benefit of choosing OIDC for our internal apps vs Okta APIs. Also we would ideally like to have the session automatically refresh when the user is logged in, but I believe that is supported by both solutions?
Let me know if you have any questions about it, we are happy to help with understanding and plug any documentation holes. One note is that the widget can do a “bridge” the Authentication API with OpenID Connect with the sessionToken: https://developer.okta.com/standards/OAuth/#custom-user-experience
If your applications, in the future, need support for user consent or IdP discovery, I would make sure you start on OpenID Connect.
Thank you for the links – very helpful. I think OpenID makes sense, my only concern is how to implement long-lived sessions. Ideally I would like a session to last for a week, in a sliding fashion, so that every time a user uses the application their session would be extended. Basically I would like a user to have the ability to login, not use the application for 6 days, be able to use it on the 7th day without having to login and have his session extended for another 7 days. Is that possible with OIDC?
Are you trying to get the Okta session to remain active? Or your SPA’s access token?
It might be easier to look at this from a Google’s POV. When I create a client app and authenticate Google, Google keeps a session. This allows me to use google apps based on their requirements, their activity and session idle time (if they had one) would be delegated by use of Google apps. The client app would authenticate against Google and keep its own session.
Replacing Google with Okta, are you trying to have session idle timeout for your application or for the Okta product? (for SSO purposes for all apps)
That’s a good question. I guess in this case it would almost be both, as I am using Okta for both the application and as an overarching SSO session manager. By having a long-lived SSO session I guess that could be used to create new application sessions if they have expired. So while the access token for the application can be short lived, I would have to have a way to transparently recreate it from the SSO session without prompting the user for credentials.