We're having an internal debate over the following issue. We have a server that implements an API that our customers' servers consume/call. Our server is using AWS Cognito. We've implemented client_credential authentication. So when we on-board a new client, we register a new app for them (in Cognito/UserPool) and give them the corresponding app id and app secret (created by Cognito). We've also set up scopes, etc. So now, when the customer's server makes an API call, it 1) gets auth tokens from Cognito using the app id and password, and 2) passes in the token with the API call.
One engineer thinks that we shouldn't trust our customers to protect the app secret. Instead, he suggests we keep hold of the app id and secret. Then, we give our new customer a username/pwd. When the customer's server makes an API call, instead of the "usual" approach described above (Oauth 2), the customer's server will 1) send the username/pwd along with the API call, 2) our server validates those, 3) pulls out the customer's app id and secret from an internal db, and 4) passes these to Cognito to get the auth tokens.
Phew! That seems a problem in several areas:
If we don't trust them with the app secret, why should we trust them with the username/pwd we create for them?
The suggested alternative (username/pwd) introduces yet another layer. Now we need to manage the username and pwd, storing it, etc.
The existing implementation (OAuth 2) is mature, tested, etc.
I'm fairly new to the OpenAuth way of doing things, so I wanted to ask for your thoughts before telling the engineer, "Thanks for your input, but we're not going to introduce the username/pwd; instead we're going to trust our customers to protect the app secret."
Thoughts? TIA.
The only thing that changes when you add another layer of username/passwords is that, when a password becomes compromised, then you only need to change the password in your system, not in Cognito.
The proposed approach could be useful if you wanted to give your clients ability to change or reset their passwords on their own, and you don't want to give them access to Cognito (either via a GUI or through some proxy created by you). Otherwise there is completely no additional value of having that second layer of username/password.
Related
Please forgive my ignorance on this topic. I've been a developer for a long time, but there's a huge gap in my knowledge and experience when it comes to authentication & authorization protocols and proper handling of tokens.
We've got a whole homegrown suite that consists of:
4 web apps (2 in Ruby/Rails, 1 in Elixir/Phoenix, 1 single-page React)
1 image server (serverless app written as an AWS Lambda / API Gateway)
1 custom data API (also serverless Lambda / API Gateway)
We also have an Amazon Cognito User Pool connected to our backend identity provider to authenticate users and generate tokens.
All but one of these allow some form of anonymous access; the other is only available to logged in users. If a user is logged in, they all need to access the user's profile info from the ID token, preferably without initiating another auth flow. Our backend apps may also need to make use of the access token, but obviously we wouldn't be handing that out to to the SPA or public API consumers.
My first thought is to store the tokens in a key/value store on the backend, and have a short-lived, encrypted JWT containing a unique session ID set on the shared domain that all of the backend apps have access to, with the key stored in a config secret. By decoding the session ID, they can get what they need from the data store. The API would also refresh when necessary.
I also know that API Gateway can use a Cognito user pool as an authorizer, but I'm unclear how I would make that work while integrating it with the rest of our apps and requirements above. Sometimes requests to the API are made from the browser (in the React app, for example), and sometimes they come from the backend of one of the web apps.
The image server and API are used by our apps, but are also documented and accessible for other people to build their own applications on. But they would have to register their apps as OIDC clients to receive any profile info from logged in users.
I'd love some advice on how to make all of this work, or at least pointers toward resources that might help make it less dizzying.
I have read rfc6749 and https://auth0.com/docs/authorization/which-oauth-2-0-flow-should-i-use but I couldn't seem to find the flow that's exactly for my use case.
There will be a native app(essentially a GUI) that will spin up a daemon on end user device. The daemon will try to call internal APIs hosted by the backend. The internal APIs don't need to verify the user identity; but it's preferred that the device identity can be verified to some extent. There will be an OAuth authorization server in the backend to handle the logic. But I couldn't identify which is the correct flow to use for this case.
Originally I thought this is a good fit for client credentials grant type. But then I realized that this might be a public client but client credentials is supposed to be used for confidential clients only.
I then came to find out about authorization code with PKCE flow. This seems to be the recommended flow for native apps but it doesn't make much sense to me as there will be redirects and user needs to interact but the APIs that will be called is supposed to be internal and user shouldn't know about these back channel stuff at all. Also the resource owner should be the same as the client in this case, which should be the machine not the user.
So which flow should I use?
Thanks a lot for the help!
Client Credentials feels like the standard option but there are a few variations:
SINGLE CLIENT SECRET
This is not a good option since anyone who captures a message in transit can access data for any user.
CLIENT SECRET PER USER
Using Dynamic Client Registration might be an option, where each instance of the app gets its own client ID and secret, linked to a user.
The Daemon then uses this value, and if the secret is somehow captured in transit it only impacts one user.
STRONGER CLIENT SECRETS
The client credentials grant can also be used with stronger secrets such as a Client Assertion, which can be useful if you want to avoid sending the actual secret.
This type of solution would involve generating a key per user when they aughenticate, then storing the private key on the device, eg in the keychain.
We have a number of apps that communicate with each other. One app goes to a customer, and it has to communicate with a central server to get certain information. We use OAuth2 authentication, and we already use username and password to authenticate access to the central server app.
We hardwire an OAuth2 clientid and a client secret into the customer app so that the server app knows it is an instance of the app talking to it. Recently we have been asked to make the client ID and client secret configurable by the customer, so that each customer will have different OAuth clientid and client secret. id and secret would be generated by the server and the customer would set the id and secret on their installation of the app.
Is this normal practice
Does it add any useful security value
References to reputable publications addressing this would be especially welcome.
EDIT: We are using Resource Owner Password Flow, where username and password, as well as clientId and secret, are stored (encrypted) in the client app. The customer who installs the app gets given a username/password/clientid/clientsecret supplied to them, and that combination is always used to connect from client app to server app, whichever end user is logged in to the client app. (The id/secret/username/password combination can be changed if it is compromised, but changing it is expected to be rare.) This effectively makes the installation of the client app the resource owner. (I didn't design this)
I am afraid to say that the way your system uses the Resource Owner Password Flow is not normal practice (Resource Owner Password Flow). When client ID, client secret, username and password are hard wired in the client app, you could as well use the Client Credentials Flow.
Adding a configurable part to the hard wired authentication, poses the challenge to supply this new part to the customer in a secure way. On the other hand it gives you the possibility to revoke the authentication of a single customer in case it got compromised. Doing this in making the client ID and secret configurable is not normal practice. If you change the client app, so that the username and password are configured by the customer you would get closer to the standard Resource Owner Password Flow. This flow is deprecated but could be ok in your case (when to use).
By doing this step the resource is no longer owned by the client, but by a group of customers and customers can be excluded from this group.
Another way would be to change to the Client Credentials Flow and make the client ID and secret configurable. This way the customers clients would appear as different clients. The effect is nearly the same.
Summed up you have two sets of credentials (client ID:secret and username:password). Today both identify the client. One way or the other you could add the ability to identify the customer.
it is not considered best practice to hard code secrets into an app, the encryption of those only shifts the problem to the encryption key; there is a specification that addresses your "dynamic client" use case, called OAuth 2.0 Dynamic Client Registration https://www.rfc-editor.org/rfc/rfc7591
This is more of a general question but I hope it is still valid for SO.
So far I have learned, that in general, a mobile app (such as official Pinterest app) use the Password credential flow to let their users login and access the API directly. (let's just assume they use OAuth for this)
So they collect username and password, send it to their server and get a token in return which is used for subsequent requests.
Now a user did not want to register and created an account using e.g. Facebook as the authorization server. So my question is:
How is this flow implemented?
My educated guess:
User chooses "Login with Facebook" in mobile app
Facebook Login Page opens with return_uri = mobile app
Mobile app receives auth token
Mobile app uses client credentials and says the API: Use this token for user X
Is this correct?
First of all, apps should not use the Password Credentials Grant. The specification is rather clear about it:
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. This creates several problems and limitations
The specification then goes on describing those problems.
And about the Resource Owner Password Credentials Grant:
The authorization server should take special care when enabling this grant type and only allow it when other flows are not viable.
The entire purpose of OAuth 2.0, I to not have to use something like the Password Credentials Grant, where the user hands over their password to the application.
About your second question: what happens when a user does not want to register and create an account with your app, but wants to use e.g. Facebook for authentication?
Remember that both the Implicit Grant, as well as the Authorization Code Grant, work by using a browser control to authenticate the user. In that browser session with the Authorization Server, you are free to authenticate your user in any which way you want. Certainly, you can use your own user/password database, but you could also use other mechanisms, such as WS-Federation. In your case, it sounds like the user want to authenticate using Facebook.
Authenticating using Facebook is then not done by your client app, but by your Authorization Server. It typically does that by using the Facebook Authorization Code Grant, followed by a call to read the user's profile to obtain their Facebook user id, name, and so on.
If you do not want to build such an Authorization server yourself, you can use an existing one. Several companies offer login-as-a-service solutions, including the one I work for.
UPDATE: You asked several follow up questions in a comment below. I'll answer them briefly here:
First of all, the fact that some companies that use OAuth to secure their services allow for a Password Credentials Grant, does not imply that you should. In fact, there are probably more examples of companies that don't offer this possibility, than companies that do.
There are real trust issues, and real security risks with sharing your password with a device app. To start with, the app on the device is easier to hack than a server. Furthermore, if you give the app your password, presumably that app also needs to store it somewhere for future use. As a user, I just have to hope that that storage is safe form possible malware running on my machine. For more issues, see the introduction in the OAuth 2.0 specification mentioned above.
Secondly, all good Authorization Servers differentiate between First Party Clients and Third Party Clients. A First Party Client such as yours is controlled by the same company that controls the Authorization Server, and for such an app the Authorization Server does not ask for user permission to share data, since it makes no sense to talk about sharing data with yourself. That is why the web sites of these companies don't ask you whether you allow to share the data they hold on your behalf with them. They already have it, and there is no "sharing" going on.
Of course, you might argue that you have never seen any of these companies talking about this distinction between First Party Clients and Third Party Clients. But the reason they don't should be obvious: when you deal with them, you are always a Third Party App. They don't need to tell you that they treat themselves differently.
The mechanism I would choose in your scenario depends on the nature of the client app, and the nature of the services it accesses. What are your requirements?
Anyway, if the device the application is running on has a secure storage facility, such as Windows Phone 8.1, I would probably consider using the Authorization Code Grant without client credentials. That way, the user never has to log in again. If we're talking about a web site or a SPA, I would consider the Implicit Grant (where the "remember me" feature, if any, is offered by the Authorization Server). Again, the specification gives advantages and disadvantages of each grant type for several scenario's.
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.