I'm working on an OAuth 2.0 server to support multiple clients and roles.
Let's say I have an API server that requires an access token from an OAuth server.
These workflow I came up with. I have three serves for this simple workflow -- OAuth, Client, and API server.
Users on each clients have email and password (these credentials are stored on OAuth server)
Users sign-in with their email and password on their clients then the clients send the credentials to the OAuth server for authentication.
OAuth server checks the credentials and issue an access token.
When a user requests an request to an API server, API server talks to OAuth server to see if the user has access to the resource. If so, perform requested request then return something.
This is somewhat unusual workflow in my opinion. The reason I want to do this way is because we actually store user credentials on our OAuth server. I also have multiple roles (groups) for each clients.
Is this OKAY workaround or is there a better way for one OAuth + multiple clients and multiple roles?
What you describe is the equivalent of the Resource Owner Password Credentials grant in OAuth 2.0, see: https://www.rfc-editor.org/rfc/rfc6749#section-1.3.3. You should be able to do this with a stock OAuth 2.0 Authorization Server that supports this grant. So it is not unusual or proprietary but requires a great deal of trust in the client because it "sees" the password.
You can model multiple roles and groups by representing them as different "scopes" that are associated with access tokens and thus clients.
Related
I have an Authorization Server with Spring Security 5. It supports Authorization Code, Authorization Code with PKCE, Implicit Grant and Client Credentials flows from the OAuth 2.0 authentication framework for it's clients. This Spring Security 5 Auth Server is also connected with a database with users information and it's passwords hashing. Currently the Auth user validates users credentials from the login page using the users tables from the database.
Right now I need to setup an AWS Cognito User Pool and use the same users already stored in the database. My intention is to use the Spring Security Auth Server as an OIDC Identity Provider for my user pool in AWS Cognito.
Is this possible?
AWS Cognito can act as an Authorization Server, meaning your apps will get AWS tokens. In this case you add Spring as an OpenID Connect IDP, similar to my blog post which used Okta as an IDP. This could be quite an impactful change though, since you may not be able to make Cognito access tokens contain any custom values.
Alternatively you can do it the other way round, in which case your apps will receive Spring issued tokens. I would expect the integration to basically work, whichever way round you do it, though you could experience some annoyances.
An important factor is how your APIs / back end will identify users from access tokens after this change, since Cognito and Spring will use different subject claims in access tokens. In case relevant, this detailed Curity article discusses migrations and user IDs.
I am reading and reading, not sure why it's so hard to properly understand OAuth2 flows, which I thought I understand, until I wanted my own server.
So I have Frontend (web + mobile app aka resource owner), my own API server ( resource server )
and I want to create my own OAuth2 server.
So assuming, that on user registration, I am registering them on my OAuth2 server, saving username and hashed password ( I also want to save organization/project name, so I can user oauth2 server for multiple projects without worry of username duplicates)
Then Frontend obtains access+refresh tokens from OAuth2 server directly with password_grant. Or should I do it through my API and use CLIENT_ID/CLIENT_SERCRET with it (is that even an option)?
With access token, Frontend then now can communicate do my API(resource server)
API (resource server) then communicates with OAuth2 to validate access token - here I am not sure what's the common name of that action authorize or authenticate ?
Once access token is expired, Frontend (resource owner) can communicate directly to OAuth2 to obtain new access and refresh token. Or again - it should go through API and do it with CLIENT_ID/SECRET ?
Currently I did above implementation, but inside my API, but idea of OAuth2 is that it is separated server. Not sure how it will benefit me other than I will be able to use it for other project, but I guess with OAuth2 I can then expose API to public.
Question is, is above correct ? can someone help me wrap it with correct OAuth2 terminology ?
The frontend apps are not resource owners, but clients. Resource owners are users of these apps. These apps are so called public clients - they don't have a secure storage for their client secret, so they must not have a client secret. Instead, they should use PKCE (kind of one-time password) with the the auth code flow.
This way, they receive a refresh token they can use to get valid access tokens. The frontend apps use access tokens to authorize their requests to your backend. Your backend should validate them.
For more info, please see the current best practices - OAuth 2.0 for Browser-Based Apps and OAuth 2.0 for Native Apps.
I'm trying to implement authentication/authorization in my solution. I have a bunch of backend services(including identity service) under API Gateway, "backend for frontend" service, and SPA (React + Redux). I have read about OAuth2.0/OpenIdConnect, and I can't understand, why I shouldn't use Resource owner password flow?
A client ( my backend for frontend server ) is absolutely trusted, I can simply send users login/password to the server, then it forwards them to Identity server, receives the access token && refresh token and stores refresh token in memory(session, Redis, etc), and send the access token to SPA, which stores it in local storage. If SPA will send a request with the expired access token, the server will request a new one using refresh token and forwards the request to API Gateway with the new access token.
I think in my case a flows with redirects can provide worth user experience, and are too complicated.
What have I misunderstood? What potholes I'll hit if I'll implement authentication/authorization as I described above?
OAuth 2.0 specification's introduction section gives one key information on the problem it tries to solve. I have highlighted a section below,
In the traditional client-server authentication model, the client
requests an access-restricted resource (protected resource) on the
server by authenticating with the server using the resource owner's
credentials. In order to provide third-party applications access to
restricted resources, the resource owner shares its credentials with
the third party
As a summary what OAuth wants to provide is an authorization layer which removes the requirement of exposing end user credentials to a third party. To achieve this it presents several flows (ex:- Authorization code flow, Implicit flow etc.) to obtain tokens which are good enough to access protected resources.
But not all clients may able to adopt those flows. And this is the reason OAuth spec introduce ROPF. This is highlighted from following extraction,
The resource owner password credentials grant type is suitable in
cases where the resource owner has a trust relationship with the
client, such as the device operating system or a highly privileged
application.The authorization server should take special care when
enabling this grant type and only allow it when other flows are not
viable.
According to your explanation, you have a trust relationship with client. And your flow seems to be work fine. But from my end I see following issues.
Trust
The trust is between end user and the client application. When you release and use this as a product, will your end users trust your client and share their credentials.? For example, if your identity server is Azure AD, will end users share Azure credentials with your client.?
Trust may be not an issue if you are using a single identity server and it will be the only one you will ever use. Which brings us the next problem,
Support for multiple identity servers
One advantage you get with OAuth 2 and OpenID Connect is the ability to use multiple identity servers. For example, you may move between Azure AD, Identityserver or other identity servers which of customer's choice (ex:- they already use on internally and they want your app to use it). Now if your application wants to consume such identity servers, end users will have to share credentials with your client. Sometimes, these identity servers may not even support ROPF flow. And yet again TRUST become an issue.!
A solution ?
Well I see one good flow you can use. You have one front end server and a back-end server. I believe your client is the combination of both. If that's the case you could try to adopt authorization code flow. It's true your front end is a SPA. But you have a backend you can utilise to obtain tokens. Only challenge is to connect front end SPA with back end for token response (pass access token to SPA and store other tokens in back-end). With that approach, you avoid above mentioned issues.
I have implemented an OAuth2 register workflow (in Java) according to rfc6749
I'm using GitLab as OAuth2 Provider.
After the user granted access to my application for his account, I get an OAuth Token (along with refresh token and other stuff), I am able to make API requests on behalf of the user, so this is working fine.
This way I can get the users e-mail adress which I use to create an internal user.
My questions are:
Is it practice to issue a token that is generated by my application for the user (along with the OAuthToken) or should I just use the token that has been issued by the OAauth Provider? (My App also has local auth with bearer tokens). This token will be used for further API - CLIENT communication (stored in Angular2 local storage as bearer)
How to do login only? When a OAuth User accesses my web service, how do I know that this user is a OAuth User and which OAuth Token belongs to him? How can the user login without providing e-mail or password? (The user has no password) I guess I have to redirect him to the OAuth Provider again, but I don't want my user to grant access everytime he logs in.
Answer 1:
Though you can use the token provided by OAuth provider, you SHOULD NOT use it considering the risk that may arise exposing it to the public.
Instead you should securely save the token provided by OAuth provider into the database and use another token for authentication of further api calls. (you could use JWT)
Answer 2:
There are two types of systems
Which always uses OAuth provider for identifying user. (Ex. Tinder)
Which provides both OAuth Login and Traditional login/signup. (Ex. Quora, Instagram)
If you want your application to follow 2nd approach, you should ask the user to create password for the first time when the user logs in using OAuth provider.
This will allow the user to log into your application by both methods, traditional as well as OAuth
To identify users of your application, you should either use HTTP session or issue your own tokens. Do not use tokens generated by the OAuth2 provider - they are meant to be used just by your backend (in role of an OAuth2 client).
To use an external authentication in your application, you probably want to use OpenID Connect, not a bare OAuth2. OpenID Connect extends OAuth2 and it's meant for authentication instead of the rights delegation. Then you use an implicit flow (instead of authentication code grant) with scope=openid, your frontend app (HTML+JavaScript) gets an ID token signed by the OAuth2 provider. After successful signature verification, your backend can trust that the client is the one described in the ID token (in its "sub" field). Then you can either keep using the ID token or generate your own token.
I am writing a web app, "B", that interfaces through a REST API with another web app, "A", that I wrote and control.
I would like for a user that is logged into A to be able to perform actions on B that use the API to communicate with A. My best option looks like OAuth, but I want the experience to be seamless, and OAuth requires that the user consent before an access token is granted.
Is OAuth a good solution for this situation? Is there a better alternative?
If I do use OAuth, can I pre-authorize consent by trusting the Consumer Key?
You can do XAuth, which is an extension on OAuth. It uses the same principles of request / access tokens and secrets, but allows you to exchange a username / password combination for a access token.
We use it like:
User logs in onto our iPhone app
iPhone creates OAuth request token request, plus sends username + password over HTTPS
Validate request (secrets etc., + username / password), generate request token, and exchange request token for access token. (This step is fully on the server, so the server does the exchanging).
Access token is returned to the user
iPhone app uses normal OAuth protocol + access token to communicate to server
Same way Twitter is doing it for apps that don't allow for an easy OAuth authentication page.
Eran Hammer-Lahav says,
The user should be in control of their
resources, but if this is just a case
of one provider spread over multiple
domains, I see no harm in skipping
granting access to a client which is
essentially owned by the same entity.
Take a look at the oauth2 client credentials flow.