Are there another ways of doing logout without redirecting my Frontend to oidc/logout page (it works fine,but isn't it insecure sending idToken and my IDP url to frontend),i have separate front and back end. Like in Keycloak which invalidates session by sending refreshToken? If not,what is a right way of doing logout in my application?
We are sending the ID_Token in POST request directly to the IS Server thus it should not have any security concerns. Using ID_Token as id_token_hint while doing a logout is coming from OIDC specification[1]. This will prevent attackers from logging out users from their accounts because only the real RP can present the valid ID Token.
If you want an alternate way to logout you can make use of session management API[2]. But it is recommended to use the logout endpoint.
[1]https://openid.net/specs/openid-connect-session-1_0.html#RPLogout
[2]https://is.docs.wso2.com/en/5.9.0/develop/session-mgt-rest-api/
Related
We are trying to implement a SSO solution using Laravel Passport. There is already a question about this topic but I think this one is more about the nitty-gritty.
Our requirements are:
A Laravel Passport service running on passport.com
Some first-party sites on various domains: foo.com, bar.com
Users can log in to foo.com and bar.com by typing their access details directly (Password Grant)
If a user logs in to foo.com and then they visit bar.com they should be automatically logged in
Based on my understanding of Oauth2, the system should work like the following:
Initial login flow:
The user types in their details on foo.com
foo.com makes a request to passport.com/oauth/token using a Password Grant and retrives an Access Token and a Refresh Token. Additionally, a SSO Token is generated and returned.
foo.com redirects the user to passport.com/sso/passthrough , passing the SSO Token and a return URL as query parameters.
passport.com saves the token as a cookie and then redirects to the return URL.
The user returns on foo.com and they can use the site
Note that the redirect to passport.com MUST take place, as otherwise browsers like Safari and Chrome in incognito will consider passport.com to be a third-party domain and the cookie will be blocked.
SSO flow:
The user visits bar.com
bar.com makes an AJAX request to passport.com/oauth/authorize using a SSO Grant and the redirect URI bar.com/sso/return
On passport.com, the SSO Grant looks for the SSO Token in the cookies and if the token is found, an authorization code is produced and sent bar.com/sso/return as a redirect. Because AJAX requests don't handle redirects, control passes directly to bar.com.
bar.com exchanges the authorization code for an access token and returns a successful AJAX response
bar.com receives the AJAX response and triggers a page refresh since the user is now logged in
For clarity, the SSO Token, SSO Grant, passport.com/sso/passthrough and bar.com/sso/return routes are not part of Laravel Passport; they are new concepts that we are implementing here.
The questions here are:
This flow looks to me like it should work. Am I missing anything?
Does this introduce any vulnerability into the Oauth2 flow? The Access Token and Refresh Token are never displayed to the client, but the SSO Token is. If an attacker steals it, I'm guessing they could potentially impersonate the user.
The Oauth2 protocol and Laravel Passport are stateless. By adding a cookie we are adding state. Is this a necessary evil or can it be done in a different way?
Should the SSO Token be saved to the cookie directly or should there be a different kind of token or authorization code there?
Any tips for implementing the SSO Grant and SSO Token?
I am maintaining this application which is set up with:
an AngularJS front end
a Spring back end (with Spring Security, configured as per the Keycloak documentation) running on Tomcat
Keycloak as single sign-on solution using OpenID Connect.
The Implicit Flow is implemented like this:
The user navigates to the web app in their browser
The AngularJS web app checks if a (non-expired) JWT token is present in the Session Storage
If not, it redirects to Keycloak to request a token
Keycloak authenticates the user and redirects back to the webapp with the token
The web app stores the token in the Session Storage
Any request the web app makes to the back end API, it inserts the header Authorization: Bearer <token>
So far, so good. However, I noticed that logging out does not work as expected:
The user clicks the logout button in the web app
The web app deletes the token from the Session Storage
The web app redirects to the Keycloak logout endpoint
The user accesses the back end API directly and succeeds!
The reason is that a JSESSIONID cookie is stored and this also authorizes the user to access the API.
My questions:
Why is a JSESSIONID cookie being created? Is it default behaviour of Spring Security? Or did I misconfigure something?
How should I fix the logout issue? Make sure a JSESSIONID cookie is never created? Or implement a logout endpoint in the backend that deletes the session cookie?
NB: I am aware of
the risks of storing credentials in Session Storage;
the Implicit Flow being deprecated.
I am working on a web application of tech stack contains front end ReactJS and backend SpringBoot 2 Microservices. Now it's time for the SSO integration **(single sign on) using the OAM(Oracle Access Manager) using SAML2 **.
I had a discussion with OAM Team and they had given me below details
Entity ID or Issuer ID
OAM Entry Point or OAM SSO URL
X509 Certificate
Assertion consumer URL (ACS URL) which i had given to them to receive SAML Response
online i could find few SSO option with SSOCIRCLE, OKTA, ONEIDENTITY etc but couldn't find any resources with Springboot2 + SSO + OAM.
Please throw some lights or any response on how to start would be greatly appreciated.
You can start with OAM installation:
https://docs.oracle.com/en/middleware/idm/access-manager/12.2.1.4/tutorial-oam-install-oam/
Refer to the following link to understand deployment and usage in application:
https://docs.oracle.com/en/middleware/idm/access-manager/12.2.1.4/tutorial-oam-protect-wlsapp/#deploy-a-sample-application-to-weblogic-server
You have to integrate below flows
Login flow: From your web application (frontend) redirect to the Federation system endpoint (get their login endpoint), this is a browser redirect. Here 2 types of configurations options are available- Either you send the xml Metadata to them when you redirect to their portal OR
These configurations can be set at OAM manually and you only have to do a simple browser redirect. (I have tried the 2nd option).
User enters the credentials in Federation page which gets authenticated by IdP and after successful authentication the SP is notified on ACS login url. So your login url will be basically a callback url which will be called by them and they will be sending a SAML response on that callback api. Once you get a notification on your callback you need to redirect the user to your portal.
For this your callback url should set http response status code as 302 and response.headers.location as the endpoint (along with saml response) where you want the user to redirect. Take care of validating saml signature before redirecting user to your portal.
On your frontend code, you will have to check for the SAML response with windows.location.search.
These steps will redirect user back to SP portal.
Logout flow: when user clicks on SP logout button, execute your logout api and then redirect user to Federation System's logout url, browser redirection, in this case User's session will also terminate at their(SAML) end and they redirect user to SP portal.
Ensure that user's sessions (both) are in sync. For this keep idle timeout and max session timeout same at both ends.
Hope this helps.
Some background:
I am writing a small SPA that will use a back end that I have also written. The JS and the back end API are on the same server.
i.e. SPA will load from foo.com, back end is at foo.com/api
In the past I have always used Spring Security with simple form based login. After logging in the user will get a session cookie. Pretty standard stuff.
For this app I looked into OAuth2 implicit flow. My understanding is the User would load my page, then from the SPA I would direct the user to the authorization endpoint so my app could get a token. The user would be redirected from the authorization endpoint to a login form. After the user authenticated with the form.. they would be redirected back to the authorization endpoint to get the token and possibly grant access to the JS client. After that the user would be redirected to a URL specified by the client, with the new access token as a URL fragment.
I have this working and its all great. The part I don't quite get is this:
When the user is redirected to the login form and they authenticate a session is created on the server that has to at least last long enough for the user to be redirected to the authorization endpoint to get the token. At that point they already have an authenticated session on my server, why not just stop there and use traditional cookie and session based logins?
I have implemented the usual username/password login process with Shiro for my single page webapp which will submit the username and password over https in production. I use a REST back end rather than a typical MVC framework of any sort to facilitate my SPA. Typically with a REST API a BasicAuth is used to log in, and in response if successful an encrypted token is returned either as a cookie or a response header. Subsequent calls would return the cookie or header to avoid having to resend username and password. Usually the token is an ecnrypted username possibly with some other info that can be derived on the server side either as a session token or something else.
Anyway, as I said I am using Shiro and I understand Shiro can use multiple realms for authentication and authorization. What I am trying to do for my web site is require the initial username/password login, then after a user is logged in, somehow avoid the Shiro UsernamePassword authentication process and instead use the token check process.
I think the right way is to provide my own custom authentication realm and credentials matcher.. and I have a public domain SHA256 salted password bit of code that stores the salt, iterations and password in one string that I'd like to use. What I am not sure of is how to configure the shiro.ini... do I need to provide two custom classes, one for my own username/password for initial login, then another for my token authentication? Or can I utilize the built-in shiro usernamePassword, and will it's rememberMe feature be good enough in jquery $.ajax() calls? Perhaps I can use the Shiro implementation but also need to attach the shiro rememberMe cookie to all my $.ajax() calls?
Just a little confused really on the best approach to provide good username/password initial login and subsequent calls without needing to resent username/password... and to support session invalidation and logout functionality.
Another thought is to not use Shiro, instead use my own servlet filter to check for the initial login, if authenticated, return the response header (or cookie) myself with my own encrypted token that I keep in HttpSession or in a database back end for the duration of the session, and make sure in my jquery ajax that after each response to look for the token, and resend it in the subsequent requests.
Thanks