As part of integrating with Okta using OIDC, I am trying to understand if we need to contact Okta to end the session when a user logs out in the app? I am able to login using Okta as an IdP and then logout from the app at which point logging in again requires contacting Okta again. So what is the real need for ending session when a user logs out?
Okta is best-placed to answer in their particular case - being the OP (OIDC Provider) that you're using, but at least in terms of invalidating your tokens - both potentially on their (backend) side, as well as orchestrating all that is required (as part of their possibly custom workflow/process) upon the client side too, so that both sides are fully aware of the log out having taken place; so yes, it's best to, for one (probable) reason or another.
Related
I used the code at https://github.com/oktadeveloper/okta-spring-boot-saml-example to understand how to use Okta for SSO. We are using SAML. My question is how to detect if the session is still valid and if not, redirect the user to the Okta log in page.
I tried using HttpSession but I did not know how to link it to Okta.
If someone can give me a few pointers as to where to start, I would appreciate it.
Thanks
The short and best answer is no.
You can use Javascript on the browser to see if the User still has a live session with Okta using this:
https://developer.okta.com/docs/reference/api/sessions/#get-current-session
There is a way using the Sessions API to authenticate a User, and then check to make sure the session is still valid, but managing the state creates more headaches than it's worth. I would not suggest doing this.
If you are using Oauth 2.0, then it's easier, you can just redirect the User to Okta and perform a re-authorize more easily, plus Oauth 2.0 tells you when the token was minted.
I work for a large company (50K+). Some orgs within the company use OKTA for auth on their servers.
I have a valid user login (via OKTA) for the servers, and can log in through a browser without any issues, but want to access this site programatically.
How can I log into these websites using my OKTA credentials?
I've found this doc: https://developer.okta.com/docs/reference/api/oidc/#authorize
that details how to use an OKTA endpoint, but it requires some info that I do not have. Namely, nonce, state, and client_id. I have no clue how to get this info.
I've found another endpoint that allows a similar login method, but only requires username and password (I forget the doc that referenced this):
https://<company>.okta.com/api/v1/authn
I am able to successfully authenticate with OKTA using this endpoint, and receive a session_token. Can I take this session_token and apply it to my arbitrary webpage somehow? I can not find any documentation that says so.
At first glance it appears that many of the API endpoints for OKTA require intimate knowledge of the hosted application (and/or are not meant to be accessed programmatically).
Is it possible to log into an arbitrary webpage that uses OKTA for authentication, with only knowledge that an end user would have (username/password/optional MFA)?
Hi not sure you found the answer yet. from your descriptions i think yours is web app, which is supposed to use authentication code flow. else, you can ask your web developers what authentication flow they use and follow the auth process accordingly.
you need to retrieve id token & access token for authentication.
As an authentication, the application (Service-X) uses a third-party internal service (Service-Y), in which all the information about the employees is stored. All internal services of the company use SSO.
How to implement the ability to log in to Service-X if Service-Y is unavailable? (If I have already been authenticated in Service-X before this).
The remember-me feature that comes with Spring Security might be what you're looking for.
However, there are still quite a few limitations to this. If your cookies are wiped upon closing the browser, which is quite common in a lot of big companies, this won't work. Other than by the session cookie, you can't safely remember the user. You absolutely require Service-Y to be available to identify the user if his cookies have been cleared or have expired.
The main selling point of OAuth2 is that you sign in using Service-Y without Service-X knowing your username/password (unless the username is transmitted through the scope), so while you could ask the user to provide a password on the first time he signs in Service-X using Service-Y in case Service-Y goes down, which would potentially patch your issue, I really do not recommend it because it somewhat defeats the purpose of OAuth2.
Now, if you do take that suggestion despite me not recommending it, you should make sure that Service-X checks that Service-Y is down before allowing the user to sign in using the password he provided for Service-X.
Best case scenario, if your browser cookies aren't cleaned, go for the remember-me feature. I suggest you read the following: http://www.baeldung.com/spring-security-oauth2-remember-me
Sorry if this is a bit long. Got a requirement to integrate our application with client's main portal site. The portal is maintained with a SAML 2.0 SSO features and as such, we'll need to integrate our login using SAML 2.0 as well.
The integration is done via an iframe, i.e. on the main portal, an iframe with the url pointing to our application. When user is logged in and click on a menu link, he/she will be presented with the iframe page, with our session checking with their IDP to make sure they are valid users. If so, then our application will continue to load as per usual.
The issue is that we'll need to maintain our session on our servers, while they shall maintain the session on their app server. If the user stayed on our site for a while, the session on the client main portal will timeout. And when the user click on the main portal link, they will be required to log in again.
It is suggested that when the user tries to navigate to the main portal pages, it will call a service (for now assuming it's an IDP) on our end to check whether the user session is valid or not. If it is, then we need to return a SAML response to them to validate the user.
We're exploring setting up an IDP service at our end to facilitates this, but it seems to be overkill to me. Is there a way for an IDP to only provides check on a user's session? Or is there a better option for us to achieve this?
Things that could not be changed:
1. SSO language: SAML 2.0
2. Server: Weblogic 10+
3. HTTPS a must.
Appreciate any suggestion or feedback.
Thanks.
Based on the provided information, I assume your application runs on WebLogic 10+. If the remote server too uses WebLogic you might be able to just implement the SAML authentication between the WebLogic federation. This will simplify everything and you don't need to do complicated application customization.
If the remote site does implement SAML and not on WebLogic, you still should be able to implement SAML authentication through the WebLogic configuration. This is straightforward and can be done without much hassle.
However, please be reminded that WebLogic 10+ does not support SAML SSO logout. Therefore, this needs to be handled separately.
We're about to start allowing our users to point their own domains at their profile pages on our website, but I've run into a problem that I can't seem to get around.
We need to make sure that when any user who is logged into the main domain visits one of these custom domains that they are going to be logged in on this site too. I've been reading about a few different approaches. SSO, CAS, OAuth... but I'm not really sure if any of these fits what I need.
I'd love to hear some opinions on it.
CAS is a SSO, it means that you will authenticate only once (just for the first app) and then you will access all app without re-authenticating.
For every app in the "CAS galaxy", you'll get the profile of the authenticated user (a set of user attributes defined according to the app).
The main advantages of CAS are its simplicity and its efficiency.
I think it meets your needs.
OAuth is about authorization : it means you will need to authenticate and authorize, which generally leads to login page for authentication and confirmation screen for authorization.