Our system architecture has this setup. We have an API that is used by a WebApp Client. We allow users to authenticate using an Identity Provider (IDP) that returns SAML.
The problem is how would you setup authentication? Which of the flow below would be more suitable?
WebApp Client controls the flow
When a user needing authentication visits WebApp Client, redirect user to IDP.
User authenticates with IDP
IDP redirect user back to webapp client with SAML response
WebApp client passes the SAML to the API.
The API will decrypt and read the attributes.
API then gives access token to the WebApp client it can use for subsequent requests.
API controls the flow
When a user needing authentication visits WebApp Client, redirect user to a special endpoint of API.
API redirects user to IDP
User authenticates with IDP
IDP redirect user back to API with SAML response
API decrypt and read the attributes
API redirects user to the WebApp client passing an access token to the WebApp client it can use for subsequent requests.
I'm currently asking myself the same questions with google idp. I thought about passing the returning code from idp to my API and then authenticating the user from my API.
If you have some return on your experience let me know :)
Related
Suppose that I have a mobile app with a frontend and a backend server.
My understanding is that -- when a user logs in the app with "Login with google", the frontend sends a request to the google auth server, and gets back an ID token. The documentation says that the frontend can then send the token to the backend server to establish a session. I imagine that means the token can be used in session-based authentication?
If I were to use token-based authentication (as opposed to session-based), do I just attach the ID token in every server request, and have the backend verifies it each time when processing a request? this page suggests the ID token should not be sent to the backend API. Which leaves me wonder what the correct procedure is for token-based authentication when using log in with Google.
So my question is: Does my server need to create an access token from the ID token from Google, and send it to the frontend, so the frontend can attach that access token in the API requests for authentication?
Thanks
Login with Google is an identity provider (IDP) operation. A full OAuth solution, including an authorization server (AS) looks like this:
Mobile app uses system browser to redirect to AS
AS returns a redirect response to the system browser, which routes to the IDP
User signs in at the IDP
IDP returns an authorization code to AS
AS swaps it for IDP tokens and carries out validations
AS issues a set of tokens to the app. This includes an access token (AT) with whatever scopes and claims are needed for business authorization to work.
Mobile app sends AT in API requests
API authorizes using scopes and claims from the access token
So ideally plug in an authorization server, to get this out-of-the-box behaviour. Another option is to implement your own token service, and issue your own tokens. That is less recommended though, since it requires more detailed understanding of the underlying security.
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 need to enable SSO between my customer's website and my API.
The customers website doesn't use Auth0 but allow users to login using a few different social providers like Microsoft and Google.
My API is secured using Auth0 and also supports Microsoft and Google authentication via Auth0. If my customer sends the JWT token received when the user authenticated with Google with their request to my API, will Auth0 authenticate the user even though my customer doesn't use Auth0?
Google/Microsoft auth is OAuth. OAuth is an explicit grant between the user and one particular application. It cannot and won't be shared with your app. The user would need to do a separate OAuth flow with your application to grant it access. There is no way around that.
However, given that this is an API, the more likely scenario is that the user shouldn't auth with your app at all, but rather, it should be the customer's application that auths and then works on behalf of the user. As such, you'd just set up the customer's application as a client and given them client credentials to use. Then, the user auths with the customer's website, the customer's website auths with your API via its client credentials, and then the user in effect works with your API via the customer's application as a go-between.
No , if your api application is protected by Auth0 and use external providers , after authentication from external providers and back to Auth0 , Auth0 will validate the token issued by external provider ,decode token , read claims , issue Auth0's own token and implement session management . So that your api application only accepts tokens which issued by Auth0 and validate tokens use Auth0's key-pairs , it won't accept other provider's tokens .
You can make your client application and api application both secured by one identity provider(Auth0/Google/Microsoft) .
Basically I just want to know how does StackExchange's single signon system work?
In the SE network you need to login only once in one of the websites to be automatically logged in to the other sites upon visiting.
How should I implement such a feature in my own network of sites?
I assume it uses the cookie which resides on the user's browser and then authenticates it with the originating site. If it is legit then it logs the user in automatically.
You have to implement SAML or oauth2 to allow sso on your network.
In case of SAML your child websites will be service providers or resource servers.
While you need to setup and identity provider.
The sequence of events will be like this.
1. User hits a url of songs website, this site is resource server and does not handle authentication.
2.To authenticate resource server will construct a SAML authrequest and redirects to identity provider after signing it.
Idp verifies the signature after receiving authrequest.
3. User will be presented with a login form, user has to end login credentials.
4. After user authentication idp will generate a SAMl token and redirect back to resource server.
5. Resource server will extract identity information from SAML token, resource server will login the user with session or cookie.
Depends upon which technology you are working in i have implemented it in php using simplesamlphp.
is there a way to ask for an OAuth authorization without redirecting the user to the service and then back again to my app?
In detail, I'm creating a web service that need access to the Facebook Graph API, that requires the OAuth 2.0 authentication. Is that possible?
Thanks
The authorization request has to happen for an authenticated (by the OAuth provider, not you) account, and for security reasons the authentication has to be a direct interaction between the end user and the OAuth provider.
Of course, the provider might decide the user is already authenticated properly (there is a fresh auth ticket in a provider-specific cookie for example) and skip the authentication sequence, but there is no way for you to force it to take your word that the user on whose behalf you are requesting the authorization indeed is an authenticated user of the OAuth provider.