4
When we use Oauth we have the "authorization server" and the "resource server". The resource server is the server on which the API is, that is, this is where the interface to the resources we want to protect is. The authorization server, on the other hand, is responsible for carrying out the authorizations and giving permissions.
I know that these two servers can be the same. Actually, just to motivate the question, that’s how I’ve always worked. I used ASP.NET Web API 2 to create Restful Apis and the framework offered an implementation of an Oauth authorization server. In that case, my application would even do both roles. It turns out that now in ASP.NET 5 no longer exists this authorization server and I am looking for alternatives.
What I want to know is this: is it correct to use an external provider as an authorization server? What I mean is to use the Oauth services of Google, Facebook, Microsoft as the authorization server when using Oauth in my API to generate the access tokens?
Reading a little of the Oauth specification seems all right. But on the other hand, I feel it’s not quite right. Two reasons I could think of were:
Those Oauth services don’t seem to have been designed for that. It seems that the intention in creating these authorization servers was precisely for them to be used for the services themselves, that is, to access the Apis of Google, Facebook, Microsoft, and not to protect other Apis.
When I heard that the authorization server is responsible for giving permissions this seemed to me equivalent to saying that it is in it that the users' Claims are defined. This makes me think the use of external providers is wrong in this case. This, because, define the Claims is something based on business rule of the application I am developing.
I have several other questions about using external providers with Oauth in API’s Restful, but I’ll leave it to other more focused questions. In this case, I want to know: it is correct to use these external providers as authorization server to generate access tokens to be able to use Oauth in Restful Apis?
If it is correct, and these two points I thought? How do these questions?
Editing: I may be completely mistaken, but I see this case of the Restful API different from the login with external provider used on websites, like here at stackoverflow.
Although this is subject to another question, the difference I see is in summary the following: when we code a website, we are automatically offering a user interface. In this case we can generate a button that will take the user to the login screen of the provider. When the user logs it back directly to the site.
In the case of a Restful API, there is no user interface. It is simply an API and the user will not access directly. There will be, in general, a client that calls this API. So you can not do in the API a login button that takes the user to the provider page. More than that, if the user goes to the provider page, through the client, how does the API get communicated later? After all, after logging into the provider, the redirect would lead the user to the client. Things seem to be disconnected in the case of the API, precisely because it happens to have a client in the middle intermediating everything.
These Oauth services do not seem to have been created for this. If it were true it would not be public interfaces and it did not need to be created this standard, each company could develop its own authentication method among the various products of the same company. It does not seem to be the case, stackoverflow for example allows login with Google and Facebook.
– EProgrammerNotFound
@Eprogrammernotfound, I was thinking that, too, but then I started to think that these services were created just to allow access to their Apis. For example, Facebook to access the Facebook Apis from other apps and only. Stackoverflow login, on the other hand, is for a website, not for an API. Then I was in doubt: these Oauth services can be used for web API authentication in addition to websites?
– SomeDeveloper
I don’t know Oauth in detail, but it’s important to differentiate between authentication and authorization: the function of authentication is to prove that a certain user is who he says he is. If a user has created an account in his service using an external provider as an authenticator, and later he tries to log in with the same provider, it is assumed that he is the same user. I, for example, have never created a Stackoverflow account, I have always used Google to authenticate myself, so the only way for the OS to know which user is trying to access the site is through Google confirmation.
– mgibsonbr
Already authorization means saying what the user is allowed to access/do and what he does not have. In the same vein, I am authenticated with the OS, but the actions I can perform (vote? close questions? remove posts?) is only the OS that can determine, no external provider knows what I am allowed to do within the OS. The problem - and perhaps there is the origin of your doubt - is that Oauth was created for authorization, but often it is used for (pseudo-)authentication. And while it makes sense for an outside provider to authenticate you, you can’t be authorized.
– mgibsonbr
@Eprogrammernotfound Stackoverflow allows logging with multiple providers, using different protocols, for example. Openid, Oauth or Facebook Connect (think). Openid for example, being federated, allows anyone to create an authentication server for themselves and use that server to authenticate with Stackoverflow. The point is that Oauth can be used for authentication by anyone, but only someone authoritative over a domain can authorize actions in this field (see comments above).
– mgibsonbr
@mgibsonbr Exact, I confused Oauth with Openid, the concepts are different but the names authentication and authorization are similar. In this case, I believe that the Oauth serves to delegate those functions (see contacts, etc, etc.) that you should accept. I believe then that AP is on the right track, consuming Oauth in your application, your application would have access to google services for example, and not the other way around.
– EProgrammerNotFound
@mgibsonbr From what I read on rfc 6747 Oauth’s idea is to standardize a secure way to share services with third parties. I don’t want to set the standard here, so I’m not answering but commenting. Reading the RFC can be quite interesting to properly understand the purpose of the protocol.
– EProgrammerNotFound