I am interested in implementing separate resource and authorization servers. Understand from here, that for this to work, "Either the tokens have to be decodable locally by the resource server or it has to share storage with the auth server." After almost 2.5 years, I hope that the resource server can resolve a token into a Principal without sharing a data source with the authorization server. As stated in this question, is RemoteTokenServices the only means to achieve this? If so what should be the response of "/check_token"?
RemoteTokenServices is not the only way (but with a bit of cacheing thrown in it can be a perfectly good solution), nor was it 2.5 years ago. The other option supported out of the box is JWT tokens (e.g. https://github.com/spring-projects/spring-security-oauth/tree/master/tests/annotation/jwt).
Related
I am novice to how oauth2 with JWT works But must to learn it in short time :) After reading bit I draw a conclusion abstract of its work as this.
now I have two question in my mind.
(1) Is my way of understanding of how OAth2 work is fine ?
(2) As far as I know after step 6 (diagram) no further request to authorization server. Then,anyone(intruder) know the token witch given by auth server can communicate to the web API and obtain unauthorized access.how does is not possible.
(I know that token not alter by intruder since then web api new that but without altering it still intruder can communicate to web api)
I know I have miss something please kindly show me where I have missed ?
You have to take security measures to protect your token from being stolen. This is no different than preventing session-id from being stolen in session based authentication.
Anyone with access to a valid token is by definition an authenticated user, no matter how the token was retrieved.
Whether your web API communicates with the authentication system directly is not relevant.
Currently, I think my understanding of OAuth and how it it is implemented in ASP.NET Web Api is flawed.
1) I keep seeing OAuth described as a server (i.e. the OAuth server). Is the OAuth implementation by a Microsoft a separate server with a different port or is it just referred to as a server even though it is self contained within the API project?
2) Is OWIN separate from OAuth or are the two linked such that they must be used together?
3) How does an OAuth v2 server keep track of tokens that have been revoked or have expired? Does the OAuth component have a database that keeps track of the tokens that it issues? If so, what type of database is it?
I have been reading the tutorials by Taiseer Joudeh from bitoftech.net but I think I am missing some of the basics.
Here are my responses:
You can implement the server as a stand alone authorization server or you can implement it together with the resource server. The Visual Studio template brings you both servers together, but you can separate them. Tutorials from Taiseer Joudeh will guide you very well, they did in my case.
OAuth 2.0 is an authorization framework, as said in its definition document. And OWIN stands for Open Web Interface for .NET. Both of them are different things, but Microsoft decided to do an implementation of OAuth 2.0 protocol using OWIN middlewares architecture. Then the easiest way to develop OAuth 2.0 servers in ASP.NET is using Microsoft.Owin.Security.* libraries implemented by Microsoft.
The OAuth 2.0 protocol does not talk about keeping track of expired or revoked tokens, you could implement if you want, but you only could do if the authorization and resource servers are both the same, and then you will need to access to database to check the token for each request, that it is not necessary. If the resource server is separated from the authorization server it has no direct access to the authorization server database. Normally you don't do that. The expiration check of the token is something that the Microsoft.Owin.Security.OAuth library makes for you. If a token received by the resource server has expired, the library responds with a 401 - Unauthorized response.
To make possible that the resource server can decrypt the token, you only need to set the same machine key in both servers' web.config file.
To avoid to have long lived access tokens you could set short access token timespan and implement refresh token. In this case, you could save refresh tokens in database and you can implement some method to revoke them.
Refresh tokens and its revokation are implemented in Taiseer Joudeh blog posts too.
I hope my explanations are clear and can help you. Please tell me if you have any other doubts.
I'm trying to implement an OAuth2 provider for my web service.
It seems easier to implement the Authentication Server together with the Resource Server. The specification doesn't say anything about the communication between them.
Does anybody see a reason not to do this?
I had a post yesterday regarding this issue. I hope we can mutual answer each other. First to directly answer your question, I think it depends very much on the load that your app has to handle. If you have to scale your app to many resource servers, keeping a separate auth server is the best because you can centrally manage user credentials and access_token in one place.
Here is my question. I believe if you have tried something similar to mine, you can give me some suggestions.
OAuth - Separating Auth Server and Resource server returns invalid token when accessing protected resource
To learn more about OAuth, I'm trying to write an OAuth 2.0 provider and also a consumer.
I'm kind of using the Doorkeeper Gem as a reference for my provider, but I'd like to write my own.
My question is about the last bullet in Section 1.3 of the spec regarding bearer tokens.
(F) The resource server validates the access token, and if valid,
serves the request.
In this scenario, does The resource server validates the access token mean that it:
checks the access token against its own locally stored copy of the access token and its expiry
makes a request to the provider server, which returns a response of valid/not valid?
does something else entirely
The specification does not answer that question, because it is an implementation detail that has no effect on the working of the protocol. Nevertheless, it is a good question that can have an impact on security.
First of all, you have to realize that in some implementations, the resource server and the authorization server are just two roles of one single entity.
As the OAuth 2.0 specification (RFC 6749) puts it:
The interaction between the authorization server and resource server
is beyond the scope of this specification. The authorization server
may be the same server as the resource server or a separate entity.
They may both be present in a single web site. Maybe they are two different web sites, but they both do have a connection to the same database. The resource server can then lookup the token in the database, just as well as the authorization server can.
If the resource server cannot read the authorization server's database, than it has to talk to the authorization server (and even if it can, it would probably be a good idea to not read the database directly).
How exactly you establish and secure that communication is up to you, but an HTTPS REST request makes a lot of sense. Many implementation have different mechanisms. For examples, see OAuth-2.0 resource servers token validation in distributed environment.
UPDATE: the standard way for a resource server to validate a token is now OAuth 2.0 Token Introspection (RFC 7662).
Obviously, when an access token is presented to a resource server for the first time, the resource server does not know about it, and has to access the authorization server to check for validity. The interesting question now is: can the resource server cache this response, or does it have to make the call on every request?
That is a design decision to be made by the resource server, and it may be influenced by many different factors. For example:
If the authorization server responds very quickly, there may be no need for the resource server to cache the response. In fact, a badly designed cache may be slower than not caching.
The need to design and implement a cache with a good cache policy may be prohibitive for implementing a good cache in the resource server.
Depending on the nature and the scale of the resource server, the cost of allocating RAM or storage on disk to a cache may be prohibitive for implementing a good cache in the resource server. This is especially true when the number of access tokens out there is very high, and a lot of storage is required to obtain a sensible cache hit ratio.
Is the resource server prepared to accept an access token, even if it has been revoked in the authorization server?
That last point deserves some further explanation. The authorization server typically has several mechanisms to revoke tokens. If a resource owner revokes an authorization through the UI, the authorization server has to invalidate all tokens obtained through that authorization (access tokens and refresh tokens). The resource server may also implement a token revoke endpoint (often used for a "log-out" mechanism in public clients that use the implicit grant).
Is the resource server prepared to take the risk of accepting a token, even after it has been revoked? And if so, for how long? If it is, then it can cache the token, otherwise it can not. At first sight, you would of course say that a resource server SHOULD NOT use cached token validation responses. But in some cases there might be performance advantages that outweigh the risk. It obviously also depends on the nature of the resources stored by the resource server, and the real risks associated with them.
Again, this is a design decision we can not make for you. From a security perspective, you should not cache validation responses in the resource server.
<context> I got frustrated yesterday and posted a flame question which was quickly (and appropriately) closed and deleted by my fellow SO cohorts. Yahoo! turned off its standard PlaceFinder API endpoint and replaced it with a paid service. That's not the part that frustrated me though, it was mostly the fact that they changed their access model to require OAuth. One of the closers of my question commented something to the effect of:
you didn't keep an eye on deprecations of API's you depend on, OAuth
is better for users, suck it up.
While I could argue the facts of my API-watching by again blaming Yahoo for having broken links when they first announced the API deprecation back in October / November of last year, I think it would be more productive to try and turn this into an intelligent question. </context>
I have used OAuth. I like OAuth. Not only does it let you authenticate users and simplify sign ons to your application, it lets you ask for authorization to access that user's data from other apps. But PlaceFinder data is not private user data. It is for known place names and global identifiers (WOE ID's) that can be shared by everyone.
This morning I gave Yahoo! BOSS GEO my credit card information and started spiking up an OAuth API consumer to test it out. I started with DotNetOpenAuth, which I have used in the past. I read through Yahoo!'s OAuth guide and created a DotNetOpenAuth.OAuth.ServiceProviderDescription instance with all of Yahoo!'s OAuth 6.1, 6.2, and 6.3 endpoint URL's. I then went about trying to figure out how to use DotNetOpenAuth.OAuth.WebConsumer to hit the PlaceFinder API and start giving money to Yahoo!.
But it didn't work. I had to overcome a lot of cognitive dissonance, and in the end, either a limitation of the popular and widely-used DotNetOpenAuth library itself or a possible misuse of OAuth. When I finally realized that the BOSS documentation was separate from the BOSS GEO documentation, and found a C# code sample that worked to consume Yahoo!'s PlaceFinder API, I discovered where all of that dissonance was coming from.
Yahoo!'s PlaceFinder API, while it uses OAuth, does not require an Access Token to get at the API's endpoints or data. When you send a PlaceFinder request, you send all of your app's information (consumer key and secret), along with the timestamp, nonce, and signature to the PlaceFinder endpoint itself. When I used OAuth in the past, these elements were sent to the 6.1 endpoint to obtain a request token. You could then use that to authenticate / authorize the user (6.2) and obtain an Access Token (6.3) to make further requests.
Here's the limitation in DotNetOpenAuth that I can't overcome so far, so if I'm being ignorant and doing it wrong here please tell me. In the sample C# code on Yahoo!'s site, they are not using DotNetOpenAuth. Instead they have an OAuthBase class that you can use to generate a nonce, timestamp, and signature. But they send empty strings for the access token and secret. I tried doing this with DotNetOpenAuth, but it won't let you construct any requests with a null or empty access token.
So the question: Is this an inappropriate use of the OAuth standard? If not, is there a limitation in the DotNetOpenAuth library that makes it impossible to send unauthorized requests to endpoints other than for a RequestToken (6.1)? If the answer to both of these is no, how could you use DotNetOpenAuth to request PlaceFinder data without having to send an access token or secret?
This is a great question. I think oAuth provides BOSS developers with two benefits
Since you sign up for BOSS once and can then use that key for multiple services, the BOSS team wanted to have the flexibility to offer more services that needed tokens in the future. Starting with oAuth right from the get go allowed that flexibility.
The team wanted to ensure that keys are not sniffed out during network communication. Since requests are signed and actual keys are not passed, we can ensure that no sniffing happens.
Regarding your question on DotNetOpenAuth, I recommend asking on the BOSS Y! group (http://tech.groups.yahoo.com/group/ysearchboss/) since we have a number of folks who have written in C#, VB.Net who can advise you. In fact it is well known that the VB.Net oAuth library (http://oauth.googlecode.com/svn/code/vbnet/oAuth.vb) has some issues with it.
There's two types of oAth that yahoo uses. One requires a key, one doesn't. You probably want the one that doesn't for general API use. Just add the secure protocol http:// -> https:// and then place /public/ in an appropriate spot of the old url like
https://somePartOfURL/public/otherPartOfURL