I will try to keep the question as clear and direct as possible.
Social authentication (Facebook) configured with Okta with redirect URI as URL to my custom webapp. This custom webapp relies on Okta for authentication.
User visits my custom webapp (unauthenticated) and clicks on the social authentication URL to login to my custom webapp.
User follows the normal flow, gets authenticated by facebook and thereby by Okta (as per usual flow) and is then redirected by Okta back to the custom webapp.
The entire flow is successful and the user can see an Okta session cookie set in their browser.
Custom webapp now needs to show the user their own profile by making an Okta API call.
Problem: How can my custom webapp identify who just logged in so that they can fetch their Okta profile using API?
I am aware that Okta knows who just logged in due to claims that facebook sends to the OAuth client (Okta), but how will my app know the identity of the user who logged in?
Thanks,
Jatin
It depends on the OAuth2 flow you've chosen for your app, but the end state is getting an id_token from Okta which contains claims about the user that just logged in.
If you've set response_type=code in your social auth url (/authorize), after Step 4 you'll get a code query param in the redirect that you can then exchange for the id_token using the /token endpoint.
Or, if you've set response_type=id_token, you should already have the id_token in the redirect - you just need to validate/decode it (more info here).
Related
A React SPA sends registration details to a backend (including username and password). Besides other things, the backend creates a keycloak user via the REST admin API.
The user then still needs to go to the keycloak login page for authentication. Is it possible to skip this step and automatically log-in the user on registration via API?
I thought if maybe the backend can obtain a token and send it to the SPA. But I do not know how to initialize keycloak-js in this scenario.
You can register the user and, after a successful registration, call the login endpoint with the same credentials in order to receive the access token.
Update:
Introduction
I have my own user account database and am building an oauth2 authorization server to centralize authentication logic across my companies' websites using authorization code grant type.
Let's say I have deployed my authorization server's login page at https://auth.my.company.com, and deployed a website at https://my.website1.com. When a user click on the login button at https://my.website1.com, the typical oauth2 authroization code flow will be triggered as shown in the picture below.
To explain the picture:
The user access to https://my.website1.com which renders a login button.
The user is navigated to the centralized login page with url https://auth.my.company.com?client_id=mysite1&redirect_url=https://my.website1.com/oauth/callback
The user enters username and password and submit the login form.
After the authrization server validates the user credential, it redirects the user back the the redirect_url https://my.website1.com/oauth/callback?auth_code=abcd passing a parameter auth_code=abcd
The website backend server communicates with the authorization server using the input auth_code to authenticate the user, the authorization server returns an access token.
The website responses to the user that the login process is success.
The Problem
At https://my.website1.com, I would like that the user can also login with his/her Facebook account, which will be bound with the account in my user account database. I would like to centralized this process as well (i.e. so that my another site https://my.website2.com can reuse the same login process). So I am thinking of implementing a 2-hop oauth flow as in the following picture.
The user access to https://my.website1.com which renders a login button.
The user is navigated to my centralized Facebook login endpoint https://auth.my.company.com/facebook
The authorization resolves its Facebook client id and redirect url and then redirect the user to Facebook login page.
The user logins through Facebook.
Facebook redirects the user back to my authorization server, passing the authroization code.
My authorization server uses the authroization code from Facebook to authenticate the user with Facebook APIs
My authorization server redirects the user back to https://my.website1.com passing its own generated authorization code.
The website backend server communicates with the authorization server using the input auth_code to authenticate the user, the authorization server returns an access token.
The website responses to the user that the login process is success.
Question
I cannot find any reference to this kind of 2-hop oauth so I am afraid that I am doing it wrong. I would like to know if there are standard approch the handle the centralized social login like this.
Found a reference from IBM website that looks very similar to the flow in question. Here
I'm trying to learn how to utilize auth0 to handle user authentication for an api I am currently creating.
My api has two endpoints:
Login endpoint: /api/login
Request access token endpoint: /api/auth?code={code}
Here the authentication flow is:
User goes to the login endpoint of my api.
User is redirected to auth0 ui.
User inputs their login credentials.
Auth0 redirects back to /api/auth where a request for an access_token is made using the login code.
Firstly, is my understanding the Oauth authentication flow correct? If so, how best should my api handle the initial login redirect to auth0?
Because at the moment when I hit up /api/login from the front-end ui it just returns the html of the login page at auth0. Should I instead return a 302 with the redirect url or is it possible to create an endpoint where the user inputs the username & password via my api and avoids the redirect?
---update---
After a user has authenticated via auth0 they receive a access_token and id_token which should my api use to verify the user is who they say they are?
Not sure if my understanding is correct but I belive that my frontend ui is the OAuth client application and my API service is an OAuth resource server. As such does my api need to call out to auth0 /userinfo to verify the user?
Assuming you are trying to protect an end-user application (your question wasn't clear on that), my understanding is if you are using Auth0, you likely won't need an /api/login and api/auth API. If you are using Auth0 you can get those things during your authentication via Auth0.
I would say your APPLICATION (not API) would redirect the user to the Auth0 login endpoint. You would do that by incorporating the Auth0 SDK of choice, depending on what you're building. For example, if you're building a web app, you may choose to incorporate auth0.js and call webAuth.authorize() to trigger the login. During that login, if you have configured an API within Auth0, and you provide the proper Scope and Audience during your login, your response will return an API token.
Then your user is in a state on the client side where you are logged in, and you have a token. You can then provide that token to your API, and your API can validate that token as needed. Auth0 also has various libraries for token validation (like this spring security one, for example).
Lastly, the question on which oAuth flow to use, that also depends on what type of app you're protecting. There are again Auth0 docs to help. The flow depends on if you're building a server-side web app, a SPA, a native app, etc. Your question was a little confusing, and it sounded a bit like you are building an API and want to protect that. If there is no client-side app (only machine-to-machine API calls), then you wouldn't be dealing with HTML and login pages. You'd likely be getting into the Client Credentials flow, which last I checked was only included for Enterprise Auth0 users.
Given an Identity Server 4, can we implement a Single SignOn being used by different applications with a single user authentication server?
If so, how can we do that? Any reference material available for the same?
In fact, there is nothing special you have to do to enable single sign-on. It's available by default, but not for all scenarios.
In order to make SSO work there is only one rule:
The user has to login on the IdentityServer website, because that's where the SSO cookie has to be placed.
SSO is not available for grant types that do not require the user to login on the IdentityServer website.
How it works:
A user visits webapp1, hits the login button and is redirected to the IdentityServer website in order to login. IdentityServer will scan for the SSO cookie but will not find it since this is the first time and the user isn't authenticated yet.
After succesful login, the SSO cookie is stored (on the IdentityServer website) and an authenticated user is returned to webapp1.
The user then visits webapp2. As long as the user is not required to authenticate the user will be an anonymous visitor.
Authentication is required when the user clicks on the login button or visits a secured page (e.g. secured by the [Authorize] attribute). That triggers the authentication flow which redirects the user to the IdentityServer website.
Again IdentityServer will scan for the SSO cookie, but this time it's found. Being already authenticated, the user isn't required to login again but is instead returned to the website as authenticated user.
Please note that the client can overrule the SSO cookie by setting the prompt=login parameter.
Also note that cookies are not cross-browser. Visiting webapp2 using a different browser will require the user to login again because the SSO cookie isn't available for this browser.
Yes you can, that is what IdentityServer4 is used for (SSO & Authentication).
There is documentation and some samples.
I have four custom apps (that are SPs), using Auth0 or OneLogin as my IdP. In Auth0 I create a connector for each application. When I login to one application and then open the other application, I get redirected to Auth0 to login again.
Is it possible to log the user into my IdP (or Auth0/OneLogin) automatically on that second app without having to click the login button on Auth0, since they've already authenticated with Auth0?
There is an unfortunate need to embed the second app into the first app and it's a poor UX to have the user login to the first app and then login again in the iFrame.
Auth0 Dev here, Yes this is supported Out of the box in Auth0, for this to work you'd have to turn Use Auth0 as IdP "ON" in your Client. When doing this Auth0 will then remember the client for 10 hours upto 3 days if the client is active.
The flow in your scenario will be
User logs in to any of the application.
User visits the other application.
The other application sees no session.
The other application redirects to /authorize endpoint.
Auth0 notices the session and redirects it back to your application immediately.
This is further detailed and explained at https://auth0.com/docs/sso
SSO is not having to re-enter credentials again but you only get SSO once you redirect to the IDP and you authenticate under the hood i.e. seamlessly.
So you still have to do something to trigger the redirect.
You could programmatically redirect to a dummy page that requires authentication that then redirects via your client stack e.g. OWIN OIDC.
Also, there is no standard for the cookies so you don't get SSO across multiple IDP unless they are federated together.
So if no federation and you login to Auth0, you will still have to login to OneLogin.