I'm trying to write a small bitbucket plugin that enables SAML 2 SSO authentication.
I've been looking at the source code of sample authentication plugins in bitbucket, and it looks quite straightforward.
However, my question is what is the best approach to handle authentication that spans over separate requests.
To do SAML SSO, you have to send a POST to the IdP via the user's browser, and then it sends a SAML token back via POST's again, but then you're no longer in the middle of authentication. So I'm trying to figure out the cleanest way to kickstart the authentication process again, my current thought is as follows:
Have my authentication handler that implements com.atlassian.bitbucket.auth.HttpAuthenticationHandler do a check to see if SAML authentication has happened in the authenticate() method, and then redirect them to the IdP if necessary. (Authentication process has stopped because of the redirect)
Receive the SAML token from the IdP on a separate servlet and check SAML token is good to use. Presuming it's all good, set a servlet request attribute (or session attribute) with the username that has been validated, and then forward the user to the original page they tried to access. This should start the authentication process again.
My authentication handler runs again, checks for the request/session attribute, and this time creates the ApplicationUser that is necessary for authenticate() to complete successfully.
Does this sound like a good approach? I had a look at the bitbucket source code for how the Crowd SSO handler works, but with Crowd SSO it doesn't need to redirect you an external login page, so it doesn't have an example of this flow.
Ideas?
Related
I try to integrate my Python app(backend client) into the Keycloak system using openid connect, why do I have to fill the Valid Redirect URIs field? From my understanding for OAuth 2.0, the backend channel just need to exchange the code for id and access tokens in the Authorization Code Flow process
Why do we need a redirect URL here, shouldn't it only filled in the front end client?
Any Ideas?
We need it to restrict to what URL we are allowed to redirect to after a successful login. We do this to improve the security for your users, because it would be a big security problem if the provider could redirect to any URL after login.
The client which receives the authorization code and the one which exchanges the code for tokens must be the same client - at least from the Authorization Server's point of view. Theoretically you can have separate applications which handle parts of the OAuth flow, but they must be using the same client ID.
Ideally, the redirect URI points to an endpoint exposed by your Python backend. After Keycloak (or any Authorization Server) finishes authentication and authorization, it will redirect the user to that endpoint together with the authorization code. This way the authorization code will go straight to the backend client, the frontend app will never have to handle it. By registering the URL you want to make sure that no one performs authorization using your client ID, but asks to send the code to another application.
Yet another OAuth2 question that isn't quite covered elsewhere.
I'm using NestJS backend, React frontend, Passport and my own DB for authentication. Trying to add an
OAuth2 identity provider (Google).
I configured my NestJS app as an OAuth Client. After logging in I'm receiving the callback at which point I have an access_token and the requested user details extracted from the payload of the id_token. This is encapsulated in a class extending PassportStrategy(Strategy, 'google') and an AuthGuard('google') and much of it is handled automatically. Code here.
At this point however, I need to maintain an authenticated session between backend (NestJS) and frontend (React). I suppose I need a JWT, but I'm wondering about the best approach:
Can I use a token provided by the IdP (e.g. id_token or access_token)? So that I don't have to worry about issuing tokens myself. I.e. the frontend receives the token (either from backend, or the IdP directly), sends it on every request, backend verifies it with the IdP on every request (verifyIdToken or getTokenInfo of google-auth-library).
One drawback here is the extra network request every time. I'm not sure if there's a need for that because the IdP is only used to identify the user, not for access to other resources. Another drawback is that I need to store a refresh token and handle when the token expires (get new one, update it on the frontend).
So alternatively, could I just issue a JWT myself and not worry about checking in with the IdP? Once the JWT expires I'd need to prompt the user to log in again. In this case, I wouldn't need to store the IdP tokens. But is this good practice? One issue I can think of is that I won't detect if the user revokes access in the IdP (until the JWT expires).
I ended up issuing my own JWT tokens and managing User sessions in my app, as described in this article: OAuth2 in NestJS for Social Login (Google, Facebook, Twitter, etc)
probably my solution would be helpful.
you could access complete source code of my app that implemented with react typescript (redux toolkit rtk Query) and nestjs included of google oauth2 flow with passport.js. resource
Alright, so I'm having a hard time understanding a proper flow here for my setup.
Goal
I want to have a proper SSO flow for my SPA app that can authenticate users into an API.
Context
I have a React application that is intended to use an Okta porta that offers both SAML (preferred) and OIDC for SSO flows. I've wrapped my static sources in a web server that serves them, and that server has a middleware that checks for cookies, and if one doesn't exist, I redirect to the IDP (Okta) for login. This all works fine for now.
Currently, my API sits on that same server, which I intend on moving to a separate server to scale independently of the website. My API must also allow other machine clients (services) to call into it, so I implemented a service account flow that uses client ID and secret as the authentication measure.
In general, my intended flow looks like this:
User navigates to my website (unauthorized) -> Web Server -> Redirect to IDP -> Assertion Callback flow -> Generate JWT session cookie -> Web Application makes API call -> API Server auth middleware validates cookie / bearer token.
The problem.
The details of how the JWT access token is generated is where I'm stuck. Currently, my webserver receives the SAML assertion and generates a JWT, which is not the same JWT claims logic as the service accounts (bleh). I'm thinking of implementing an Auth service instead to centralize the token generation flows.
For the Auth Service, I've looked into OAuth2.0 and it seems like just the right approach for what I need. With that said, I can't find much information on patterns to follow for SAML assertion -> OAuth2.0. I saw an IETF draft for saml2-bearer grant-type, but it seems dead in the water. I'm also unsure about the general consensus on custom implemented OAuth2.0 grant types.
What does a proper flow look like? I have a couple of scenarios in mind:
SAML Service Provider within the same service as the Auth
Service. On lack of SSO session, my application redirects to my Auth service, which then redirects to my IDP. The IDP calls my SP (the auth server) with the assertion, the auth service generates a token, then my auth service redirects back to the webserver with a cookie placed in the response headers.
SAML SP as the webserver Since the webserver is the only system that needs to use the SSO, I could just keep the SAML flow within that process. Once my webserver receives the SAML assertion callback, my server makes a call to an endpoint service with the assertion claims, and then my auth service returns the access token in a JSON response.
Something else, like OAuth2.0 authorization code flow with PKCE for the web application. Or OIDC instead of SAML for SSO.
OIDC sounds like the right choice for you as APIs are involved. OAuth is designed to secure APIs' compared to SAML which is built for enterprise SSO.
You can integrate your SPA with Okta using OIDC. Okta provides SDK's for varies platforms to make it easier for you to do so. You can find SDKs' here:
https://developer.okta.com/code/angular/okta_angular_auth_js/
Once you get an ID token and Access token from Okta after OIDC flow, you can use the access token to access external API's. Your API resource server or the API gateway can validate the access token. Again Okta provides SDK's to verify access tokens: https://developer.okta.com/code/dotnet/jwt-validation/
I'm working through building a prototype of an IdentityServer4-based process where I have an Angular SPA, a "Back-end for Front-end" (BFF) ASP.NET Core API, and a back-end API service (also ASP.NET Core) all interacting with a derivative of the https://demo.identityserver.io/ IdP.
My BFF and back-end API services are based on the samples found at "https://github.com/leastprivilege/AspNetCoreSecuritySamples/tree/aspnetcore3/BFF"
Everything is going pretty well until I try to create the scenario where the user chooses to logout from the IdP Logout page. The BFF service does not 'notice' the user's token and session has been revoked/removed until the tokens expire much later.
I suspect I should be using the process found in the sample https://github.com/IdentityServer/IdentityServer4/tree/main/samples/Clients/src/MvcHybridBackChannel where a cookie event handler in the BFF service implements ValidatePrincipal(CookieValidatePrincipalContext context) to make an explicit call to the IdP to verify the user's token on each request.
First question: is this the correct pattern to accomplish this? Or am I making this needlessly complex?
Second question: what is the method to ask the IdP "Is this session still valid?" (This seems like something that should be easy to do!)
Thank you in advance.
First question: is this the correct pattern to accomplish this? Or am I making this needlessly complex?
Yes it it correct, when you logout directly from IDP you need to inform the client apps that user has signed out. If you are using cookie on the BFF you need to do the same for it. Read more here
Second question: what is the method to ask the IdP "Is this session still valid?" (This seems like something that should be easy to do!)
Idp is not validating the session or cookie, it validates the token. session/cookie management is the responsibility of client apps. Read more here
I go to my application and check if there is JWT cookie
If it is there, I parse it and start to verify if user have access to my application
If it is not there, I will redirect user to authenticate in FusionAuth
After successful login, user will be redirected back to my application
How do I specify in step 3 fusionauth id of my application?
And how do I specify that I want to redirect to my application after successful login?
I assume that fusionauth is running on fusionauth.mydomain.com and application on myapp.mydomain.com and JWT cookie will be issued in mydomain.com, so it will be visible for both.
Yes, this is possible.
In step 3, you will redirect the browser to the FusionAuth login page. Navigate to Settings --> Applications in the FusionAuth UI and click on the green view button for the application in questio.
This will bring up a dialog which will show integration information (if you're on a recent version of FusionAuth).
You'll see a link something like this:
OAuth IdP login URL: https://fusionauth.mydomain.com/oauth2/authorize?client_id=ee31103f-2fc1-4bb5-ba95-ac543693503e&response_type=code&redirect_uri={your URI here}
The client_id parameter in this case will identify your application to FusionAuth.
And how do I specify that I want to redirect to my application after successful login?
This is configured in FusionAuth as an authorized redirect, and then you specify this same URL when redirecting to FusionAuth to login. Notice the redirect_uri parameter in the example URL above. There is a screenshot of this configuration here: https://fusionauth.io/docs/v1/tech/oauth/overview
I assume that fusionauth is running on fusionauth.mydomain.com and application on myapp.mydomain.com and JWT cookie will be issued in mydomain.com, so it will be visible for both.
FusionAuth does not currently drop cross domain cookies. If you are running FusionAuth at fusionauth.mydomain.com the Cookie will have that same domain and not be visible to myapp.mydomain.com.
If you want to leverage FusionAuth, then you do not need to inspect the cookie on myapp.mydomain.com, you'll simply redirect the user if they are not logged in and then if the user already has a SSO session on FusionAuth, they will be seamlessly redirected back to your application.
You can review our login workflows to identify the one that fits your requirements the best and then follow the recommended workflow. https://fusionauth.io/articles/logins/types-of-logins-authentication-workflows
This appears to be a standard OAuth Authorization Code Grant workflow. We have this workflow and many others documented here:
https://fusionauth.io/articles/logins/types-of-logins-authentication-workflows
My guess is that your specific workflow is likely the Authorization Code Grant for Single-Page Applications using JWTs and Refresh Tokens that is documented here:
https://fusionauth.io/articles/logins/spa/oauth-authorization-code-grant-jwts-refresh-tokens-cookies
The way that this works is that you start the OAuth workflow from your application by redirecting the browser to FusionAuth's /oauth2/authorize endpoint. You will need to supply this information to start the OAuth workflow:
client_id - this can be found under the Application configuration in FusionAuth
response_type - for the Authorization Code grant, this will be code
redirect_uri - this is the location you want the user to return to after they log in with FusionAuth. You must configure this URI in FusionAuth under the Application's OAuth configuration tab.
If you are running FusionAuth 1.6.0 or newer, you can also click the "View" icon for your Application and it will display a pop-up dialog that will contain the OAuth URL. You will still need to specify the redirect_uri though. Here is the documentation page for the Authorize endpoint:
https://fusionauth.io/docs/v1/tech/oauth/endpoints#authorize
Once you have that working, you will need to write the Controller for your redirect_uri. This Controller will take the code from the URL that FusionAuth generates and call the /oauth2/token endpoint. This process will exchange the authorization code for an access token, which is a JWT.
The documentation for the /oauth2/otken endpoint is located there:
https://fusionauth.io/docs/v1/tech/oauth/endpoints#token
This will help you implement your Controller.