In my application, I request the user provide their password for certain actions. This attempts to ensure the person performing the action is reconfirmed as the current user.
However, with OAuth I am not sure how to, or if it is possible, to get the authentication provider to reconfirm the user. There doesn't seem to be a consistent way to get a provider to require the user to reauthenticate.
Other than modifying my OAuth authentication flow for each provider, is there a way to require a user to reauthenticate?
Or, in the context of OAuth, is there a better way to replace this pattern?
You can do this based on scopes, where the app initially redirects like this:
https://login.example.com?client_id=xxx&scope=openid ...
To perform high privilege operations the app gets an access token with a high privilege scope. You can force re-entry of the password using the OpenID Connect prompt=login parameter. Depending on the type of data involved, you can also inform the user in a consent screen:
https://login.example.com?client_id=xxx&scope=openid payment&prompt=login
The Authorization Server could also be configured to require multi factor authentication for high privilege scopes. You could then avoid re-entry of a password via prompt=none and prompt only for a second factor.
After re-authentication, a high privilege access token is returned to the app and sent to an API. The API only allows these operations when there is a high privilege scope.
Related
In my initial implementation of my app I used OpenIddict's ~/connect/token action via the Password Flow to validate a users' username and password. When the username and password was right, the user would receieve a token with their scopes etc, as per the OAuth2 spec.
Now, I'm introducing One-time PIN to my app (OTP). If a user signs up with the app, but wants to skip OTP validation, they should be able to. But in doing so, they will not recieve their full list of scopes - they will just get the basic scopes until they validate their account. This is because a user could be scoped for admin access or something but shouldn't recieve that scope until we have validated their email address as being legitimate. Unvalidated clients should still be able to use the app to an extent, just not with their normal permissions (if they have any fancy permissions).
As far as I can tell, I can't modify the OpenIdConnectRequest to add in a OTP or something like that, so how can I use an OTP in an OAuth2 password flow, using OpenIddict?
(Also, if reading the above sounds like pure unmitigated insanity, and I'm introducing horrible security holes in my app so big you just want to howl at the moon, please tell me.)
TLDR : Switch to Authorization code grant and use OTP in front end, prior to requesting tokens
I would advice you to migrate to Authorization code grant and avoid using resource owner credential grant. There are two reasons for this. First, OAuth 2.1 specification will remove the resource owner credential grant (source). Further, as you have identified, OTP and token request combination does not go along.
Hence, best options would be to switch to Authorization code grant and use OTP in front end.
Request end user credentials
OTP step - can be skipped
Token request
Binding OTP skipped or provided state is up to the OpenIddict implementation.
How do i get access to the currently authenticated users access token in a Keycloak Service Provider Interface when the user has just logged in?
Current situation:
I am doing a manual Password Grant with Apache HttpClient inside a custom User Federation/Storage Provider when the user is performing a login with username and password.
The users access token is then used to call an internal API with his authentication context. This API call with the users bearer token is required for auditing/GDPR purposes since the user gives multiple consents when logging in.
I am assuming there is no way to get the current users authentication context within a user storage provider since the user is not yet authenticated at that point in time, right?
Is password grant the correct way to obtain a user auth context/token at that time? Another option might be to chain SPIs, e.g. use an Authentication SPI and intercept the token there. But it seems you cannot overwrite an existing Auth flow.
The last and maybe best option would be to create an Event Listener Provider. But do i have access to the access token there?
I would really appreciate some input because this whole endeavour feels a bit off.
Another option (which makes more sense for me) would be to use a client id to authenticate as a service (client authentication), in order to perform the auditing. That way you don't even need the user to be authenticated at that point. I see it as a better solution, since, apart what I have said, auditing is actually a system related chore. If you let any user do auditing, they could script some code with a valid token to perform massive/fake auditings by their own.
It makes more sense to leave it to a concrete client, with a concrete role and request that role for the auditing process.
I am using Identity Server 4 for authenticate user from a single application page. For the need of the project, I have to use the resource owner password flow.
Identity Server and my application work fine together. Identity Server give an Access Token and I can use this token to access some API that we own.
However, I was asking myself about the Access Token, users and socpes. For now my setup is this one.
I have an API that require the scope API-1.
I have a client (my SPA) where I defined the scope API-1
And I have a user.
In this configuration, it is the client who own the right to access the API, not the user. And I'm wondering how to give this scope to the user and not anymore to the client.
Stupidly, I'm wondering if user can own the scope and not the client. Maybe I've miss or misunderstood something, so please teach me.
In the Resource Owner Password Flow your client will always need to have permission to the scope that your resource is protected by. This does not mean that you cannot protect your API based on claims related to the user however.
If in your API for example you need different permissions based on the user accessing the API look to use the claims information as part of your authorization. In the Resource Owner Password Flow example at http://docs.identityserver.io/en/release/quickstarts/2_resource_owner_passwords.html you will see that it mentions this at the foot of the page, see the two paragraphs as follows:
When you send the token to the identity API endpoint, you will notice one small but important difference compared to the client credentials grant. The access token will now contain a sub claim which uniquely identifies the user. This “sub” claim can be seen by examining the content variable after the call to the API and also will be displayed on the screen by the console application.
The presence (or absence) of the sub claim let’s the API distinguish between calls on behalf of clients and calls on behalf of users.
From the Valance documentation it looks like the user is always required to enter credentials at the D2L site. Is there a way for Valence to be used, without the user re-entering credentials, when a user is already authenticated by the originating webapplication? Is some type of SSO available?
Yes, In the typical configuration for SSO between a web app and the Learning Suite the same authentication service is used (either the Learning Suite itself, or a separate authentication service , or possibly the webapp that is calling in is also acting as an authenticator in the case of a portal). If any of these scenarios apply, SSO will work as follows:
Authentication is done within the browser so if the user is authenticated already and goes to the authentication service it will already have the session cookies associated with the authentications service. Therefore when the auth step is triggered it will be pass through -- meaning the user is not prompted for credentials (on the first use the user will be prompted to allow access to this app).
Additionally note that Valence APIs do not use session tokens that are subject to hijacking and instead uses ids and keys (http://docs.valence.desire2learn.com/basic/auth.html) that are used to perform signatures. As a result those keys are long lived. Apps do not need to reauthenticate the user to the LMS if they still have keys from a previous execution of the app (these keys will be reset in certain circumstances so callers must be prepared to respond to a reset key). As a result you would not typically reauthenticate a user to the Learning Suite every time the user has a session.
(if the above does not apply other SSO scenarios may possible)
After a real brain bending session today I feel like I understand 3-legged OAuth authentication fairly well. What I'm still having trouble understanding is the use of the User ID. The examples I have seen so far all seem to just arbitrarily assign a user ID at the top of the sample script and go. That confuses me.
Most of the sample code I have seen seems to center around the concept of using a user ID and the OAuth server's consumer key for managing an OAuth "session" (in quotes because I'm not trying to conflate the term with a browser "session"). For example, the database sample code I've seen stores and retrieves the tokens and other information involved based on the user ID and consumer key field values.
I am now in that state of uncertainty where a few competing fragments of understanding are competing and conflicting:
1) If my understanding of the OAuth session details record or "OAuth store" lookups is correct, via the consumer key and user ID fields, then doesn't that mandate that I have a disparate user ID for each user using my application that connects with an OAuth server?
2) If #1 is correct, then how do I avoid having to create my own user accounts for different users, something I am trying to avoid? I am trying to write software that acts as a front end for an OAuth enabled service, so I don't need to have my own user records and the concomitant maintenance headaches. Instead I'll just let the OAuth server handle that end of the puzzle. However, it seems to follow that the downside of my approach would be that I'd have to reauthorize the user every session, since without my own persistent user account/ID I could not lookup a previously granted "good to revoked" access token, correct?
3) What bothers me is that I have read about some OAuth servers not permitting the passing of a dynamically specified callback URL during the requesting of the unauthorized token, making the passing of a consumer key and a user ID back to yourself impossible. Instead you specify the callback URL when you register as a developer/consumer and that's that. Fortunately the OAuth server I'm dealing with does allow that feature, but still, if I was dealing with one that wasn't, wouldn't that throw a giant monkey wrench into the whole idea of using the consumer key and user id pair to index the OAuth session details?
This is an answer to the question by Lode:
Is it correct that not only the provider needs to have user ids (that sounds logical) but also the client? So the client (using OAuth as a login system) needs to create a user (with an ID) before successfully authenticating them via the OAuth server. Making you have a lot of empty user accounts when authentication fails or access is not granted.
It's possible to use OAuth for authentication of users without having local accounts at the consumer application, but you've got to have some kind of session mechanism (cookies/get params) in order to have some internal session representation in which you would store the oauth_token.
For example, if someone has landed to your web application, and your application is a consumer of some OAuth provider, you will have to create a local session at your site for the end-user: for example with a cookie. Then you send the end-user to the OAuth provider for authorization of a token, so that your application can get protected resources from the provider. Currently you know nothing about the user and you don't care about his identity. You just want to use some protected information from the provider.
When the user comes back from the provider after successful authorization and brings back the oauth_token, you now have to store this token in the session that you previously created for the user. As long as you keep your session (and the token if it's needed for further requests for resources), you can consider that the end-user is logged in. In the moment that you delete his session or the token expires, you can consider him no more logged-in. This way you don't have to make your own users DB table or storage mechanism.
However, if you need to have some persistent information about the users in your application, that will be used between user sessions (logins), you have to maintain your own users in order to know with which user to associate the information.
As for the difference between openid and oauth - from the perspective of local accounts, there is no difference. It's all the same. The difference is only that with openid you receive immediately some basic user info (email, etc.) while with oauth you receive a token and you have to make one more request to get the basic user info (email, etc.)
There is no difference however in regard to local accounts, if you're going to use OpenID or OAuth.
I will try to tell my view on the issues that you raised and hope that will clear things a little bit...
First, the idea is that the OAuth server is protecting some API or DATA, which third party applications (consumers) want to access.
If you do not have user accounts or data at your API behind the OAuth server, then why would a consumer application want to use your service - what is it going to get from you? That being said, I can't imagine a scenario, where you have an OAuth server and you don't have user accounts behind it.
If you just want to use OAuth for login of users, without providing user data through API, then it's better to use OpenID, but again you will have to have user accounts at your side.
Your point is correct that you make lookups via Consumer Key and (Your) User ID, and that is because of the protocol design.
The general flow is:
OAuth server (Provider) issues unauthorized Request Token to consumer application
Consumer sends the end-user to authorize the Request Token at the OAuth server (Provider)
After end-user authorizes the token, an access token is issued and given to the consumer (I've skipped some details and steps here, as they are not important for what I want to say, e.g. the consumer receives valid access token at the end)
On the authorization step, it's your OAuth server that create and save as a pair - which local user (local for the provider) authorized which consumer (consumer key-user id pair).
After that, when the consumer application want to access end-users DATA or API from Provider, it just sends the access token, but no user details.
The OAuth server (Provider) then, can check by the token, which is the local USER ID that has authorized that token before that, in order to return user data or API functionallity for that user to the consumer.
I don't think that you can go without local users at your side, if you are a provider.
About the callback question, I think there's no difference if you have dynamic or static (on registration) callback URL in regard to how you handle OAuth sessions with consumer keys and user id. The OAuth specification itself, does not mandate to have a callback URL at all - it's an optional parameter to have, optional to send every time, or optional to register it only once in the beginning. The OAuth providers decide which option is best for them to use, and that's why there are different implementations.
When the provider has a static defined callback URL in the database, connected with a consumer, it is considered a more secure approach, because the end-user cannot be redirected to a 'false' callback URL.
For example, if an evil man steals the consumer key of a GreatApp, then he can make himself a consumer EvilApp that can impersonate the original GreatApp and send requests to the OAuth server as it was the original. However, if the OAuth server only allows static (predefined) callback URL, the requests of the EvilApp will always end at the GreatApp callback URL, and the EvilApp will not be able to get Access Token.