I have SSO/SAML working using the OKTA Apis with my SP. My question is, is there a way to get the current OKTA session Id from within my application?
You can get the session status client side using the https://org.okta.com/api/v1/sessions/me API. To note, the /sessions/me endpoint doesn't require an API key and is also CORS enabled.
The only other way to get the session id is to have created it via the API and saved it somewhere, usually in a cookie, so it can be retrieved later.
Related
I have a problem where the user still can call the API after logout the application by using POSTMAN. There is no problem with the browser side after logged out since I have removed the access token and clear the cookies. But the user still can call the API and get the results using POSTMAN, which means the back-end doesn't invalidate the OAuth token. This may cause security issues if anyone stole the access code.
I have think to apply validation before the API called. I will add a column in the database table which its' value is either login or logout to indicate the current user status. Then, I will fetch this value from database for every API called to do validation. If the value is logout, then the API will return some error message. Is it possible to do by using the spring security?
I have the following scenario that I am curious if it is possible to implement. I need to use SSO and more specifically OneLogin to authenticate the user via custom UI from my Java standalone application. I know this can be done via Create Session Login Token and then Create session via token One Login API calls. With some parsing I can get the session cookie out of the last call and store it.
Now I need to programmatically hit the API server, which is to be build still and this server somehow needs to validate the session cookie that I am going to send along with request. The key word "Programatically" as in there will be no browser
OneLogin doesn't provide SDK to validate existing session cookie => it would be nice if I could, based on session cookie find out if it is still valid and what is the user name used for this session. If session is invalid API server would return unauthorized.
Is this even possible? Or is it possible in some other way?
Basically One Login is already used in our ecosystem and I have to continue using it
The app that will log user in and get the session cookie may not be the one calling the API server. This could be another java application that would receive the session
I guess what I am looking for is Validate Session equivalent from Open ID Connect API in general API
The session_token that is returned via that API has a short expiry is only intended to be used for making the Create Session request which returns session cookies.
It sounds like OpenId Connect might be the best option for this use case. If you have user credentials then you could use the Resource Owner Password Grant flow to authenticate the user and obtain an id_token.
The id_token is a JWT containing user details can then be verified for authenticity by checking its signature, audience and expiry claims. It can also hold other custom information about the user that may be used by your backend application.
We have a web app in which we allow users to log into the app using any Open ID provider(e.g. Okta, Google, Facebook etc.). We want to implement the correct Open ID Connect prescribed methodology/workflow to keep the user logged into the site.
The existing implementation, looks at the expiry of the Access Token then if it's close to expiry uses a Refresh Token to get a new Access Token to keep the user logged in. I feel like this is wrong. When a user logs in to the web app, the Identity Token is used to Authenticate the identity of the user using the Authorization Code workflow. The Access Token and Refresh Token are stored on the server side. Periodically, the Refresh Token is used to get new Access Tokens to keep the user logged into the site. I believe this is a security risk because -
Imagine if a user is logged onto his OP account in a browser. He opens up Sky and is directly logged into MP because he’s already logged into MP. He then in a separate tab, logs out of his OP account. He will continue to be logged into MP for days on the basis of this Refresh Token/Access Token mechanism! Isn’t this a security risk?
If feel like the correct way to go about this is to use Session Management using iframes as prescribed here on OIDC -
https://openid.net/specs/openid-connect-session-1_0.html
For more context, when a user logs into our WebApp we pull data from the OP's UserInfo endpoint to create a profile within our WebApp and set permissions/roles within our app based on data sent over from the OP's UserInfo endpoint. We continue doing this periodically. For this purpose, I feel like using the Access Token(and using the Refresh Token to get new Access Token) to access the UserInfo API is correct because it conforms to the OAuth 2.0 concept of protecting/authorizing API/Resource endpoints using Access Tokens.
I want to know if this is indeed the correct way to manage how a user should be logged in when supporting Open ID Connect.
I think the first question is whether you want to bind the lifetime of an OpenID Connect provider Single Sign On session with the session of your application. You just want to authenticate a user using their OpenID Connect service. If I logout of Google, I expect to be logged out of GMail, but not a third-party application that used Google for authentication. Would you like to implement Single Sign Out as well?
But if I wanted to be logged out when you logout of the OpenID Connect provider, I would implement the OpenID Connect Session management. There is one thing good to be aware of when using iframes and cookies - browsers have an option to "Block third-party cookies" (that's how Chrome calls it), it's turned off by default, but as far as I know, it disables the SSO functionality when turned on.
I'm not sure why you request the userinfo endpoint periodically. If you just want to check whether the access token is still valid, you could also use the token introspection endpoint.
For security concerns, I would suggest you to read the OAuth 2.0 for Browser-Based Apps RFC. It recommends using the auth code flow with PKCE instead of the implicit flow. With the implicit flow, access tokens transported in redirect URLs stay in network and browser caches and can be used right away by an attacker. The auth code with PKCE needs a code_verifier (one-time secret) in order to be exchanged for tokens. So I would first check how the providers work with a configuration you choose and if it's even supported.
I was creating my own oauth2 server with SSO enabled for Google and Facebook. I found this example https://github.com/spring-guides/tut-spring-boot-oauth2 to be very useful and I was able to make my oauth2 server expandable after several tweaks.
For session storage, I used redis and everything seems to be working with the spring magics.
However I encountered a session problem when implementing logout. According to single sign on best practice, when a user logout from one client, all other clients with the same session from the auth server should also be logged out. So I added an endpoint for each client to invoke upon successful login to register it's name based on the user session from the auth server. However I noticed that each time I refresh the page on my client web app, I get a new session from the auth server. As a result, each time when I try to logout, the session associated with all registered clients will always become the old one.
I've been searching for solutions online but no luck yet. It would be greatly appreciated if someone could help me with this issue.
TL;DR version:
I implemented an oauth2 server with SSO enabled for Facebook with Spring Boot. After I successfully logged in with my Facebook account, I can see my client web app resources. Every time I refresh the page, I see a new session gets created from the oauth2 server and it gets stored in the redis storage and all the old sessions are kept in the storage as well.
UPDATE
It seems that all the new sessions are generated by anonymous users each time I refresh the page.
Ok after some digging, it turns out that anonymous user by Spring Boot is not much different from unauthenticated users, according to this doc https://docs.spring.io/spring-security/site/docs/current/reference/html/anonymous.html.
It makes sense that every time I refresh page a new session would generate. My problem was that I wasn't using the correct session ID when registering client app upon successful user authentication. Therefore I override "SavedRequestAwareAuthenticationSuccessHandler.java" file so that I can obtain client_id from the request parameter and then register the correct session ID obtained from the Authentication object to this client ID.
Using the OktaSignIn widget, I see I can get res.session.token. Can I use this (or some other attribute) in another app -- with the APIKey -- and validate that this is a valid session?
We just want a simple to use auth system and don't want to set up OpenAuth...
Can't seem to find any APIs that do what I need.. but could have missed it of course...
Edit. Basically... our front end uses the OktaSignInWidget... then we want to use this in a Bearer token our API Services layer can validate.
Thanks!
Looks like this will work...
/api/v1/sessions/me
Get id from this.
{"id":"102wtHeHhr4Q4q4rh2Fjy6pGA","userId":"00u9uwkfyfiz3Y7uk0h7",
Then... this can be passed and using the API key...Issue a GET to...
/api/v1/sessions/102wtHeHhr4Q4q4rh2Fjy6pGA
Returns...
Session...
The call to /api/v1/sessions requires the API key -- which is fine.
As you mentioned, you can use the session id to see if the session is still valid on the Okta server by:
Exchanging sessionToken for okta session
After redirecting back to your app, calling /api/v1/sessions/me to get the sessionId
Using that sessionId in the request to /api/v1/sessions/id with an apiToken to see if it's still valid
This will exist as long as the user has not logged out of Okta, but the browser state might be different - for example, the Okta session cookie will normally be deleted when the user's browser closes, while the session might still exist on the server.
Alternatively, to check if the browser session still exists, you could make the validation check on the client side by making the request to /api/v1/sessions/me - the one gotcha is to make sure that CORS is enabled for both the domains your apps are running on so they have permissions to make this request to Okta.
The above methods work, but it does sound like what you should be looking into is Okta's API Access Management (OAuth2) - it was designed for this type of flow (passing Bearer tokens to your API services layer).