This is an API related question that applies to the APIs that I'm working on and would like to know the standard way of doing this.
say a user1 has created accounts so he can access it by
GET /accounts
but when he accesses transactions for a particular account
GET /accounts/acct1/transactions
how would this API know that the acct1 actually belongs to that user1 and is not the case where user2 is accessing user1's accounts.
This api is accessed via a Mobile app using Oauth 2.0 tokens. So while the access token control the access to API endpoints, how do we control access to only specific user's data at that endpoint. (using scopes?)
I've been looking at Spotify's apis and they seem to be doing this via v1/me end point.. Still reading...
I'm a noob at this and it looks to me that this should be documented somewhere in a standard manner in some RFC, but I couldn't find it and would appreciate direction
Can you provide more details on your use case? Why are you using OAuth?
It sounds like you need an authentication protocol - i.e. a protocol to let your server know who is accessing a particular API.
To quote the OAuth website:
OAuth 2.0 is not an authentication protocol
OAuth's main use-case is letting one application perform operations on behalf of a user of another application.
As an example, if your server wants to post a message on Facebook on behalf of a user, you will use OAuth to obtain a token from Facebook which lets you post messages on behalf of the user. Note that, in the most general case, your application does not know which user is represented by the token. Indeed, the user may not even be a (registered) user of your application - they only have to be a user of Facebook.
Practically speaking, you often can use the token you have to query Facebook for the identity of the user. So your server would extract the OAuth token from the request headers and use it to issue a query to Facebook's Graph API to obtain the user ID.
Note that the user is a Facebook user rather than a user of your app, so you will need to somehow map the Facebook user ID to your own users and permission system - i.e. check your database to ensure that the user has permissions to do what they asked to do.
This is the mechanism that is typically used when using OAuth like an authentication protocol (which, as quoted above, it is not).
I should add that if your app obtains an OAuth token and passes it to your server for the purposes of authentication, then this flow is not 100% secure, as discussed for example here, so make sure you do proper risk analysis for your case. In a nutshell, a determined attacker can theoretically impersonate your app and obtain tokens representing other users.
Related
I've done a fair amount of research on the many different ways to authenticate and authorize users who use my frontend application to access my REST API. I've built a system that uses OAuth2 and JWT and need a sanity check since I'm working on this alone.
For a bit of background, my frontend is built using Vue.js and my API is built using Django with Django Rest Framework. My team is already planning on concurrently developing the mobile and desktop versions of this app which both would require authentication and authorization as well.
To keep things brief, I'll omit the alternative solutions I have and just talk about the most controversial one.
Right now, OAuth2 (my authorization server) grants users a JWT token using ROPC when they provide their email and password to my frontend client. I should note that my API (my resource server) and authorization server live on the same machine.
My application allows users to essentially signup using different plans (for example a free plan and a paid plan). When a user signs up for a free plan, I need the frontend application to not only disable certain features and elements in the UI, but also I need the authorization server and or resource server to limit what that user is allowed to query based on their plan.
The idea is when a user signs up or logs in, my authorization server will get the associated user record from the database and create a valid JWT with a claim attached that states the user's plan and maybe some other non-personal information. Then once signed it sends it off to the user where the frontend can enable/disable parts of the UI... etc. Hence, if a user logs in on mobile, we can customize the UI based on the same claim sent by the JWT.
My issue is that I don't know if this is a good way to go about it. It seems that everyone I've asked in my circle is split on using JWT or not. Those apposed mostly raise security issues, but, when from what I understand, many of the JWT security pitfalls are well documented and can be avoided just using some commonsense as with any other session/token-based authentication. I'm starting to get analysis paralysis. Please help.
CLASSIFICATION
I would say this is really an API Authorization question, as opposed to an OAuth question:
The role of the Authorization Server and tokens is really just to prove the user's identity
Product specific logic comes after the user logs in and is generally best handled in your app
MY PREFERENCES
Here is how I would handle it:
Save the plan type to your product data when the user signs up
After login, look up the user from the access token
Then look up the user's plan type from your product data
Produce a Claims / Principal object in your API containing both
Enforce business rules based on the plan type claim
I would aim for a Claims object something like this:
class ApiClaims {
// The user id in the access token
userId: string;
// The email
email: string;
// The plan type
planType: string;
// Other claims from the token
// Other claims from product data, eg user roles
}
RESOURCES
If interested in this approach, these blog posts of mine may be of interest:
User Data Management
API Authorization
JWT?
You need some kind of API credential that is sent in HTTPS messages and is web and mobile friendly, so I would use JWTs. You could follow the same pattern with any API credential though.
It depends on what you are trying to protect of course, but JWT bearer tokens are an industry standard. Since you control both the client and the authorization server, you can implement it however you like.
I would look into changing Resource Owner Password Credentials flow to authorization code flow. It will enable you to use social authentication providers like Google or Facebook to sign in users (while still maintaining plan info in your own service). Chances are that people trust those companies more to keep their credentials safe than your company, and it allows you to benefit from any authentication features (MFA) those companies implement.
Also, if you want the clients to read the contents of the token, you should use OpenID Connect id_tokens, as those are guarenteed to be in JWT format.
Account Linking provides several ways of linking users to their own accounts such as their Google account or Twitter account.
I chose OAuth in Actions on Google website to do OAuth 2.0 Authorization Code Grant for obtaining access token in exchange for data resources. When I linked a user to a Google account Google Sign-In enabled, the fetching of user information was easy because the data is stored under payload, but OAuth implementation does not seem like it produces user data under payload inside User object.
So should I make an API call to the third party to fetch the user data and store that personal data to a database in this case? I wondered if there is a way that Google prepares on behalf of developers. If not, then greeting a user who visits my app again by saying 'Hello, {person name}' gets tedious...
You have two options with Account Linking.
In the case you describe, you're providing an OAuth endpoint and getting an auth token from the Assistant, and you are responsible for taking this token and using it to determine who the user is so you can get whatever you know about him. The token is one that you issue and control, so presumably you have that info in your database already. If you are reusing a token from another service, that service should be able to tell you who they are.
It sounds like you're using using a Google Sign In, however, in which case it is easier to use Google Sign In for Assistant. Once the user has signed into your service (either through an app or webapp) and granted permission to your service, then they will also be able to gain access through the Assistant. You will get an id token which can be decoded to get profile information about the user including their Google ID and name.
Our current setup is
IdentityServer4
Angular + ASP.NET Core application
Authentication for the app via implicit flow/oidc.
We want to provide APIs for customers, i.e. third party clients, with restricted access (separate set/subset of claims). These clients are mostly non-interactive scripts that download data.
This means that we cannot use any flow which (occasionally) requires user interaction. Personal access tokens, like in github, or some other generate once, reuse for a long time API key or token would be needed.
The long token lifetime would not be a security issue, because the token should only allow access to a few read-only APIs and only for that customer's data - so the responsibility to handle the token(s) falls onto the customer.
The customer should be able to create and revoke such API-access tokens based on their claims. Some users might only claims to access certain APIs.
It would be good if we could later prevent that the user re-uses the same token for multiple clients because of licensing requirements but that is perhaps an entirely new question
How could I achieve this?
I thought about doing this via a custom grant, similar to a delegation grant: user uses app, which calls the asp.net core API, which performs auth with that custom grant, persists that token somewhere (just a plain table in the database full of customer-api-only tokens? I'm not sure about that) and shows it to the user - which can also retrieve it later from storage.
I'm thinking about doing the "delegate"-authentication via our API so that we don't leak the secrets into the Angular application.
I think that we then should be able to have either long-lived access tokens or at least refresh tokens via that custom grant.
2017-12-12 how I think I could solve it
We want a process where the user generates something in our application (i.e. via our client) and this something can later be used by the user's third party client to access the API - or request an access token and then access the API.
We want this access to be tied to the user. This includes
- Disabled user
- Lockout
- Specific claims (e.g. tenant)
This does not lend itself well to a solution that issues access tokens directly, because the token would remain valid even if the user was disabled or locked out. Which means that we cannot use a custom grant or IdentityServerTools to issue tokens directly.
Therefore we should use the client credentials grant, or something similar to it, as this could yield new, short-lived access tokens.
User actually generates a new client, which is pre-filled with claims from the user (such as the tenant - which is immutable) and has a claim that corresponds with the user. This happens transparently. Password should be user-supplied with the option to change it. We only store the relation between user and issued client-ids, no passwords.
We have to create a custom grant, which works similar to client credentials, but also checks if the corresponding user is active etc. (which I think should be possible by injecting UserManager)
Resulting access token lifetime is short, interaction with our APIs is expected to be short-lived.
Assuming it is safe and easy enough to write such a grant, we should be able to cover everything we need.
Of course, I might have completely overlooked something :)
Call me a newbie, call me dumb, rate down this topic. Do as you like, I'm just here to ask a question and hopefully learn something from it.
So I've been making an API for my website today (well attempting to) and I've noticed this "thing" on most popular sites API's such as Twitter, Foursquare, Tumblr called "OAuth". From my research today I have gathered that it's basically a way of giving the consumer a token to access restricted data from the provider depending on what the user chose without the user handing over their password and username.
But why do I have to use OAuth, why can't I just give out an API to the consumer key and they just use that? I will then see if the user has allowed access for the application, and they will have to grant access for the app to take information from their account, such as photos.
Something that also confused me is why the Tumblr API uses both. It seams on reading blog details they use a simple api key but posting on blogs you need an OAuth Signature.
OAuth is a protocol and has a set of specification defined by some expert group to define how to share data.
Basically what you are seeing is just a part of the OAuth mechanism,and there is a lot of communication and hand shaking mechanism to ensure the security of user data as well avoiding unauthorized access to data.
OAuth mechanism exits at 2 levels
three-legged authentication
Two-legged authentication
Both have their positives and negatives and there are a set of procedure which needs to be taken care for security and data integrity.
Allowing access only based on access_token/consumer key is really a very weak security mechanism and can easily be hacked by any one who happens to get access to your consumer key while OAuth system make sure by sharing a time bound access_token.
For details refer to this thread oauth-2-0-benefits-and-use-cases-why
Why use the proposed OpenID OAuth Extension over another OAuth-based protocol?
Discovery doesn't seem to be a feature. Although the consumer only needs a claimed identifier to start the authentication process, any authorization will still require that the consumer knows the access token URL, signature methods, and have a shared key/secret with the provider.
One benefit is that there's a specified way to ask for specific authorizations, the openid.oauth.scope argument to the authentication request. And one specific benefit for this is that authentication only - for the benefit of the consumer only, with no verifiable token - is defined for free and can be performed without worrying about keeping track of outstanding tokens or the resources they might require.
Are there examples of alternative ways in use to specify the scopes to be requested, perhaps with something in OpenID discovery? Or could this be handled effectively with some kind of REST navigation before the OAuth process, where one of several request token URLs specific to the desired scopes is discovered by interpreting hypertext starting from a well-known URL?
I am researching a delegated authentication and authorization system with several authorization scopes, where the scopes are relevant for different interactions. In other words, the consumer needs to tell the provider which scopes should be presented to the user for authorization.
The OpenID+OAuth extension really has only one significant advantage over standard OAuth:
If you need to authenticate the user and access the user's private data, and the OpenID Provider happens to also be the OAuth Service Provider (the user authenticates with the same service that holds his private data), then the extension will help the user have just one redirect to the OP+SP instead of two separate ones. For the user, this is a huge usability win -- if he happens to be authenticating with his SP.
The risks of supporting the extension is adequately supporting users whose OP and SP are not the same entity (you don't want to say you'll support the extension and then inadvertently lock out users whose OP is not also their SP).
Keep in mind what you really need to know. If you only want to access the user's private data, but don't really care who the user is that you're interacting with, use just OAuth. No reason for the user to give up his identity via OpenID if you're only downloading his photos to offer a photo printing service, for example, or if you already have a non-OpenID account for this user.