I am looking at using the new Spring Authorization Server. I have got the samples working and seen how the test users are validated but have a question about where the user registration function should be added.
Should this be added to the authorization server or another separate service (e.g. userprofile)? If it's the latter, I assume I would have to connect the auth server to the user database.
Ideally, I would like users to click a login button, they are taken to the login page on the auth server. If they don't have an account, they create one and then they are taken back to the app with a token.
I was looking at the openid connect initiating user registration spec but don't think it has been implemented.
Related
Does ORY Hydra currently have a feature that verifies if a client is logged in via OpenID Connect? I notice there is an API to logout via front-channel
When a user revisits the identity provider, however, I have no way of knowing if they are currently logged in or not. They could delete their client-side HTTP cookies and then I am out of sync with Hydra. Meaning: Hydra has them as logged in, but I have them now as logged out. Also, in the event of a back-channel logout, I want to be able to query for this state.
Is there an API I am overlooking that allows me to know whether a client currently has an active OpenID Connect login via Hydra?
It appears as of right now the only thing one can do is redirect the user to the authorization endpoint since we have no way of knowing if they are authorized or not.
The following two tables that ship with Hydra seem to be the source of truth for the data I am after: hydra_oauth2_access and hydra_oauth2_authentication_session. Does it ever make sense to query those directly if there is no supported HTTP API out of the box to see if a user has an active authentication session?
Sending an authentication request via a redirect to the Provider including prompt=none addresses this use case: it will silently login and return new tokens if there's an ongoing SSO session at the Provider, it will return an error code login_required if not.
Notice there will never be explicit user interaction in both cases so this is convenient (and meant) to run in an hidden iframe.
LOGGED IN STATE
An OAuth client is most commonly a UI application with multiple users. Each user's logged in state is represented by an Authorization Server session cookie that neither the application or user have access to:
The Authorization Server (AS) issues an SSO cookie, to be stored in the system browser for the AS domain
Both Web UIs and Native UIs send it implicitly on subsequent requests, when they invoke the system browser
AUTHORIZATION REDIRECTS
When an OAuth UI redirects the user, it is generally unknown whether:
The user will be prompted to login
The user will be signed in silently (eg the user could have signed in to another app)
For a Web UI it is possible to send an authorization redirect on a hidden iframe with a prompt=none parameter. If the user needs to sign in a login_required error code will be returned. See my Silent Token Renewal Page for further details.
This is not fully reliable however, and has some browser issues in 2020. Also it may be unsuitable if you are using a different type of client.
FEDERATED LOGINS
In some setups the AS redirects further to an Identity Provider (IDP), and the user's login state is further influenced by an IDP session cookie.
There is no way for an app to get hold of the user's IDP login state, since the app only ever interacts with the AS.
IS THERE A USABILITY PROBLEM?
If so, post back and we can discuss further ...
I've a site which will hopefully use a third party service for logging in (through use of OAuth2 and OIDC). I understand 90% of the process involved but am failing to get what I see as the final step. I'll describe the steps as I see them here and maybe someone can help me fill in the gaps. In my set up the Resource Server and Authorisation servers are the same machine.
This is the login process as I envisage it.
User comes to my site (let's call it Site A) and clicks login
They're redirected to the authentication site (Site B) where they
input their username / password.
Assuming correct credentials they're then redirected back to Site A with an auth code.
Site A takes this auth code and in a back channel communicates with Site B
again asking to exchange the code for a token.
Site B provides an access token to Site A (not to the end user, to the server)
Site A then communicates with Site B again (Resource and Authentication servers are the same in this scenario) and gets the relevant user detail.
So the user is authenticated and we know what claims they have, however, what I don't get in the above scenario is how Site A knows who I (the end user) am.
I never logged in on Site A so presumably no cookie was set. Basically I've gone to the site, been redirected to another site, logged in there and then am redirected back to Site A but is there a cookie set at that last redirect to identify me?
I've read plenty about this online but haven't found a clear answer.
Also, am I correct in thinking that in authorization code flow that the access token never gets to the user but instead resides on the application server?
If you really want to know who the user is on SiteA, it has to be the user from SiteA's own user database. It makes sense if SiteA is not just a proxy for SiteB's API and has its own users, permissions and functionality.
To figure out who the user is on SiteA you will need to match all your SiteA's users with Auth Server's users.
Part 1. Import your existing users into Auth Server
If you control Auth Server, import all your current users into its user database. Every one of them will have Subject ID (Id on Auth Server side). Copy those IDs back to corresponding users in your SiteA's db: your SiteA's User table will have new column, for example:
userid, user_name, user_last_name, user_auth_id (new column)
if you can't import all your users, it gets complicated. The only way I can think of: you will have to log those users in twice - once into OIDC provider and once in SiteA and then associate SiteA's user with OIDC user.
Part 2. Matching the incoming user to the internal user in SiteA
In successful response from OIDC Server you will get ID Token back. It contains sub claim with Subject ID of the user. When you've got that, you will need to do a lookup in your internal DB and find a corresponding SiteA's user. If you did not find one, create a new user at SiteA (if all existing users had been imported)
Once you know who the user is, log them in to SiteA like you would normally do (give them a cookie for example).
OpenID Connect auth servers provide the userinfo endpoint, which Site A can use for getting info about the user who authorized the access token (or the authorization code). For the auth provider (Site B) to be able to do it, it needs to keep association between a token and its user. So there is no cookie for this purpose.
You are correct about the auth code flow - the access token stays at the backend - there is no need to send it to the frontend / user.
To be able to pair the tokens kept at the SiteA backend with the consequent requests from the browser, you have few options:
You can use a backend session with cookies, which is very easy, because most backend frameworks have a built-in support for it. The cookie is sent automatically with each request and the tokens can be stored in a session object. This solution may be harder to scale - if you need a cluster.
You can create your own session implementation - either by using cookies or by some identifier expected on REST API as the Authorization HTTP header value. The backend session data can be kept in some distributed storage, such as Hazelcast or database. The session identifier can be in form of signed JWT, so you can keep user info in it.
I'm building an app that requires users to authenticate with Salesforce. However, the problem I'm encountering occurs when Okta (SSO) steps in to authenticate the user automatically. The user is authenticated and redirected to the Salesforce home page, rather than the OAuth callback redirect as configured in the connected app (and passed as query param).
This is happening between steps 3 and 4 on this diagram:
Question: Is there a way I can prevent Okta from automatically authenticating a user on a page?
Just wanted to circle back and post my answer. It was simply the authorization server url. Instead of directing a user to a specific Salesforce instance (i.e., "na17.salesforce.com"), use the Salesforce auth server (i.e., "login.salesforce.com"). This keeps Okta from identifying the specific subdomain and trying to authenticate.
I have to authenticate user either by saml or by database credentials depending on how user wishes to get authenticated .
I am stuck with two problems
1)I am receiving the saml response to the call back back url. I am not sure how to integrate it with devise.
2)I am not sure how to authenticate the user either by database or by saml response dynamically based on user choice.
Any suggestion would be really helpful
You will have to use a WebView to embed the logon page in your App.
If the user chooses Database logon you will have to challenge the user to submit their user name and password. Once the user is identified by your API, your business logic will be kicked in.
If the user chooses SAML login, it will be federated login and you will send the Authen Request to the Idp. The Idp page will be rendered in WebView within your app. Once the Idp will identify the user after logon process, they would redirect the page to the URL as specified in your Authen request for the attribute AssertionConsumerService. You will have to intercept the Request to extract the SAML token which you will have to eventually submit in a API service in your environment. The API service will have to do the token processing and will generate a User profile that is identical to the one generated by the database authentication.
I recently implemented SAML with Devise in my application, and found that the omniauth-saml gem is the quickest route to getting it to work. It will handle your callback flow, usage of the ruby-saml library, and all the other details that would be a pain to implement on your own. And if you need to handle an arbitrary number of SAML providers, omniauth-multi-provider-saml worked well for me.
In my requirement, i have users in the IS. And I need to log into other applications by entering his user name and password. then the application should call the service provider which is defined inside IS and check whether the person who is trying to log into the application is actually authenticated user, then user name, email and user permissions also should be sent to the application as the response from the service provider.
I'm using OAuth2. Using Is 5.1.0.
Can anyone please guide me how to implement this
Can I check it with rest client tool like postman also?