I am currently in the process of wrapping my head around OAuth2 and OIDC. I know what all the grant types are (namely the grant types "Authorization Code", "Client Credentials", "Device Token" and "Refresh Token"). However, these four grant types do not include an option to pass a username and password. I get that there is a password flow, but this grant type is forbidden according to the Security Best Practices.
I also get the problems with the password flow, but I do not know how to replace it - after all, the user needs to enter their credentials at some point.
Is there anything I am missing? I would have thought that there is a single, trusted client that uses the password flow and that all other clients are redirected to, when a user wants to sign in.
I think I understand this issue a little better now although I may be projecting my own requirements on to your question a little bit here.
The Password Grant flow previously allowed a single client to authenticate multiple end users with the API. Let's say you run a shop and your delivery company have an API. Your shop sets up a client and each of your staff members can log in to their own account via the client.
In this case to log in they need to provide the client ID and secret as well as their username and password which Password Grant allows.
However in order to pass the user credentials to the API, the client needs to handle them in plain-text.
That's where the Authorisation Code flow takes over. Essentially it defers the login process to the API and the user enters their credentials there.
But what if your client is the API user? The shop users log in to the shop application and the shop application authenticates with the delivery API as the shop not the end user.
The Client Credentials Grant is the appropriate choice here. The documentation talks about using the Client Credentials Grant "outside of the context of a user" but this doesn't mean that the client itself can't be associated with user within the API identified and verified by the client ID and secret.
In this case the client has all the credentials is needs to handle logging in to the API without requiring intervention from the user.
In any situation where the API handles the authentication of an end user, it is fair to expect the user to be actively involved in the process and therefore to be able to interact with the login screen provided by the API via the Authentication Code flow.
Related
As far as I understand, Authorization code with PKCE is suitable for public client. Let's say I have two client_id here user and staff, User only has 'read' scope while Staff has 'write' and 'read'.
Imagine in a situation where an expert user trying to impersonate as a staff so he changed client_id from user to staff and generated his own code_verifier and hashed with sha-256. After he logged-in successfully with his username/password and client_id=staff now he can request for an access_token with his generated code_verifier and gain 'write' and 'read' scope. I think that should be possible to do right since PKCE doesnt require client_secret so you can use any client_id that you want.
if that's so how can I secure my staff client, I have two login pages one for the user and another one for staff both are public client.
API AUTHORIZATION
The main problem here is relying solely on scopes for authorization. Your example write scope means this:
Grants write privileges to the client, when the user qualifies
The main authorization in any real world system should be done based on claims issued to the access token.
In your example this might be represented by a claim such as role=user. Or perhaps authorization could derive from the token's subject claim. After authentication, when the access token is sent to an API, a 403 would be returned for the user who changed their client ID, since to he API might require a staff role.
WEB AND MOBILE CLIENTS
If the client is a web app, then using a backend for frontend would help to prevent authentication for the wrong app, due to a client secret being attached by the BFF.
For mobile clients, there is an emerging trend for the app to use its Apple or Google signing key as a proof, to attest its identity, before authentication can begin, This is not mainstream yet though, so you may not be able to use it.
SUMMARY
Consider OAuth flows that prevent client impersonation. Always authorize based on the user identity, to prevent escalation of privilege attacks.
I am very new to the concepts of SSO and Keycloak. I am trying to read the official documentation of Keycloak. In the "Supported Protocols" part (https://www.keycloak.org/docs/latest/securing_apps/index.html), the documentation talks about the two use cases of using OIDC like this:
"The first is an application that asks the Keycloak server to authenticate a user for them. After a successful login, the application will receive an identity token and an access token. The identity token contains information about the user such as username, email, and other profile information. The access token is digitally signed by the realm and contains access information (like user role mappings) that the application can use to determine what resources the user is allowed to access on the application.
The second type of use cases is that of a client that wants to gain access to remote services. In this case, the client asks Keycloak to obtain an access token it can use to invoke on other remote services on behalf of the user. Keycloak authenticates the user then asks the user for consent to grant access to the client requesting it. The client then receives the access token. This access token is digitally signed by the realm. The client can make REST invocations on remote services using this access token. The REST service extracts the access token, verifies the signature of the token, then decides based on access information within the token whether or not to process the request."
What I do not understand is this: In the first paragraph it talks about an application making a request and in the second one it talks about a client. But aren't applications counted as clients? Why the specific differentiation? And can anyone given an example of the remote services that is talked about in the second part?
Thank you.
But aren't applications counted as clients? Why the specific differentiation? And can anyone given an example of the remote services that is talked about in the second part?
Yes exactly it. The reason for the differentiation is because there could be many applications more than just this one client. And the client, that the user is authed against may want to access all those other applications' data.
For example take the google ecosystem. Does google email have access to drive, and photos, etc... While it could out the box, it doesn't. You need to explicitly allow email "offline access" to those other applications, even though they are all part of the same platform.
Keycloak understands this and provides that terminology. But it is a bit confusing because this isn't the best way to think about it. Instead a better explanation is that there is just the user and service clients. The service clients all talk to each other and ask for a user's data. While a user may want their data by going straight to one application, other applications may want that user's data too.
Assuming you want to actually allow one service to ask for user data from another service, you want to be using something that supports authorization as a service and not just authentication. There are some examples of this, such as PolicyServer and Authress.
I am reading about oauth2 now, and trying to understand its purpose. From all the resouces I read, it seems like oauth2 is only used when a webapp (say a game app) that has some users and the app wants to access a user's Facebook or Google data (some sort of data such as name or email, etc). This part is clear to me. However, things that remain unclear to me are the following:
For example: If I have a webapp, and I want the users of my webapp to log into the webapp with their login and passwords (just like how you do it with gmail) without using any third party. Does oauth2 also serve this type of authorization?
I have seen webapps, where they just let users sign up with IDs and passwords, then they salt the passwords and store the salts in the database. So when a user logs in later, they salt the password the user entered, and compare this salt to the salt in the database (created during the signup). If equal, then the user logged in. This does NOT seem like oath at all to me. So if this is not oauth, what standard is this? And are there any other standards for "direct login" like this?
Assume that I want to allow users to sign up and log in to my website, but let them log in via a third party (like Facebook or Google). This is just for authorization purposes and assume that my app has no plan to post on their facebook or request their facebook data except that I may want to use their facebook email as the user ID for my webapp. Does oauth2 serve this type of authorization?
Sorry for the naive questions, because I only read about oauth recently.
For sign-up/login without 3rd-party, as Kevin pointed out, each programming/web framework usually comes with a popular library that once, it will generate all the sign-up/login pages, database tables, flow, etc., for you. The only thing you then do is call a method provided by the library that returns the current signed in user, in your backend code when you need to figure out who the user is.
Using salted password scheme is NOT related you OAuth2 at all as you pointed out. It is a widely used scheme for local authentication because it has many benefits but I will just highlight 2 here:
a. A password when transmitted from user to server for authentication over the Internet is not sent in cleartext but rather in hashed format. Thus even if it were eavesdropped, the password will not be divulged.
b. Since each password is salted, even 2 same passwords will not have the same hash because each have different salt. Thus even if a password hash was eavesdropped, it cannot be reused at another service that the user uses the same password because the other service expected a password hash generated with a different salt.
OAuth2 is all about Authorization (asking a user for permission to perform something on her behalf at another web service, e.g., ask a user for permission to access her email address registered on Facebook). Using it for Authentication can be insecure (for OAuth2 implicit flow). Why? The end result of OAuth2 is an access key associated with a permission, e.g., 'permission to access email address'. When you use the OAuth2 result (access key) for authentication, it means that you are making the assumption that 'permission to access email address' means the user successfully authenticated with Facebook, which she did, so it seems fine. However, imagine if another site also uses OAuth2 for authentication as you did; if it receives an access key with 'permission to access email address' it will assume that you have authenticated with Facebook so it will grant you access to the account belonging to the email address. You could actually use the access key you got from a user, and login as her in the other site, and vice versa.
To use OAuth2 for authentication, you need to use it with OpenID Connect (OIDC), because the end result of OAuth2-OIDC contains an id_token with the aud (audience) field identifying who the access key is for (https://openid.net/specs/openid-connect-core-1_0.html#IDToken), which prevents the access key from being reused where it is not intended. The full explanation with easy-to-understand diagrams is here: https://www.slideshare.net/KhorSoonHin/the-many-flavors-of-oauth/36?src=clipshare
Another very simple but perhaps unnerving to a security-conscious way to do use OAuth2 for login is to use the Resource Owner Password Credential, where your website acts as a middle-man between the user, and OAuth2 provider (Facebook).
Show 'Login with Facebook' button
When user clicks on button, prompt user for Facebook username/password
Use the username/password to login to Facebook to confirm authentication and get access token.
If you don't have to time to read in-depth about OAuth2, perhaps this side-by-side comparison of all the OAuth2 flow can help.
This is courtesy of https://blog.oauth.io/introduction-oauth2-flow-diagrams/
You could use OAuth for local logins like this, but you don't have to. It might be easier, depending on available libraries, and it might make sense if you anticipate making your service available to third-parties in the future. For many sites, though, using OAuth for local logins would be overkill.
Standards are most useful when different actors need to speak a common language so they can interoperate. For local logins you don't need a standard because you're not interacting with any third parties. Many web frameworks include their own variation on the same basic flow.
I think you're asking whether OAuth makes sense for authentication (establishing identity) when you don't actually need any authorization (permission to access third-party resources). It can indeed be used that way, but lots of people will warn against it since it wasn't designed for that and has some security weaknesses in that context. See, for example, Common pitfalls for authentication using OAuth.
Scenario
We are building a new RESTful API for our web application. This API will serve our mobile applications, our web application and authorised customers.
We are using Apigility to build the API and are making use of the OAuth2 implementation it provides.
Currently, our web application relies on a users table, with permissions assigned to each user. These users simply log-in using a web form, and the session is then stored and appropriate permissions checked upon access.
We want to be able to authenticate API access (such as our web app, and authorised customers), so no unauthorised access to the API can happen. However, we also want to authorize the permissions at a user level, therefore some sort of user authentication must also happen as well.
Any authorised access to the API may use a different user, so relying on a single user per client will not work, especially since the permissions are on a per user basis. We also do not want any user to be able to use the API without prior authentication, so wanted to avoid adding every user as a client to OAuth2.
For example:
The web app is authenticated with the API with two users using it:
UserA has user management permissions
UserB does not have user management permissions
Therefore, UserA can POST to /users and receive a 200 OK while UserB should receive a 403 Forbidden.
What we have tried
We have created an example application, and have successfully set up authentication using OAuth2 for the high-level clients and can make calls as expected. But we have not been able to create an authorization model for our users based on this.
We though adding a custom HTTP header with a user token that is provided after an authenticated call to /user/login. But we are not sure if this is the correct method.
The question
How can we both authenticate the high-level clients (such as our web app, or authorised customers) but then authorize access based on the user actually using the system?
You have a few options available to you:
Token-level permissions
You can provide different tokens for each user account, and tie permissions to the token. This runs the risk of the wrong tokens being mixed up with the wrong users. However, this also has the advantage of not having to maintain a user<->token relationship, as the permission is decided at the token level. How you decide which token to generate can be tricky.
User-level permissions
You can tie a user account to a token and that user can then be given read/write permissions. This reduces the risk of a user having a wrong token as they're linked. With this method, you can use the same method of token generation for all user accounts as the token is ignorant of the permission, but does allow them "access" to the API (thus preventing unauthorised access).
I've deliberately avoided mentioning specific types of authentication tokens, as these two concepts can apply to most of the popular choices on the web (token-based, OAuth based).
OAuth has no concept of Identity.
You should look into using OpenID Connect which is a profile on top of Oauth 2.0.
In section 1.1 of RFC 6749, there are four roles: resource owner, resource server, client, and authorization server.
Does OAuth become redundant or unnecessary if the client and the resource owner are the same entity?
For example, I have a closed API and a front-facing web server. (The front-facing web server would be both the client and the resource owner.) I am trying to decide whether to switch to OAuth 2 authentication instead of using the current username/password authentication method. Is there any added security for moving to OAuth 2 if the API remains closed to third-party applications? (That is, no third-parties will ever have access to the API.)
Thanks!
In the case where the Resource Owner and Client/Resource Server roles coincide OAuth 2.0 may become less relevant from a security point of view, since one of the primary objectives of OAuth not to expose primary credentials of the user to the client becomes moot. That is also the reason why the so-called Resource Owner Password Credentials grant is considered to be a legacy/deprecated flow.
However, it may still make sense to follow the OAuth 2.0 pattern for a number of reasons:
the ability to leverage a standardized protocol through stock libraries and
frameworks without relying on custom code
the fact that in your case the Resource Server is still made strictly OAuth 2.0 compliant, dealing with Clients presenting access tokens, irrespective of what the Client/Resource Owner relationship/implementation is; this would make it easier to allow for 3rd-party client access in a future scenario
the fact that you concentrate verification of user credentials on a single path between Client and Authorization Server so each of your Resource Servers don't need to be bothered by checking user credentials individually, possibly dealing with different authentication mechanisms
and perhaps most importantly, also security-wise: once the user has authenticated through the Client using his primary credentials, the Authorization Server can issue a refresh token as well as an access token; the Client can store and use the refresh token to a new access token when the old one expires; this frees the Client from storing the primary user credentials if it wants to keep accessing the API for a long period of time without requiring explicit user interaction and authentication and makes the resulting system less vulnerable for leakage/loss of user credentials since the user credentials (password) are not stored in the Clients
If you have the following issue then you should use OAuth;
Let's say you a Gmail like web mail provider. Some of your users are using a third party app which logs in into your user's account and auto replies certain emails for you. Or you are Facebook like social network web site where some of your users use a third party app which analyzes your friend networks and prints a 2D graph for you. In this case your users are giving away their usernames and passwords. How would they prevent a certain third party app accessing their account after they gave away their username and password? Simply by changing their password. Now you have another problem; other third party apps won't be able to access the user's account. Then the user have to re-give away his password to other apps he trusts. Now this is problem too because it is not user friendly. OAuth is simply a temporary password that your user gives away to a third party app developer. He can revoke it whenever he wants without changing his own password.
Other than that OAuth is unnecessary. Just use a session cookie if you are not going to have third party app developers. It is a random string stored in user side. And on the server side will have whatever you want. Just look how PHP sessions are used and stored on server side. You can define their lifespan and refresh time automatically from php.ini.