Oauth API authentication with external provider

Asked

Viewed 632 times

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:

  1. 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.

  2. 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.

api security-guard rest authentication oauth2

  • 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, 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?

  • 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.

  • 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.

  • @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).

  • 1

    @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.

  • 1

    @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.

Show 2 more comments

1 answer

1

About the question

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?

The use of external authorization server depends on the type of application you are developing. I recommend reading the Oauth 2.0 documentation beforehand and, if you are interested, viewing examples via this link: Oauth 2.0.

Important/critical application

If this application has critical questions, for example: a school system that presents very important information and cannot stop working, I recommend that: a) use a simple authentication developed by you or; b) develop your own Oauth server.

In this case, it doesn’t make sense to stop working because Facebook or Google stopped for some reason or if it can perform a procedure on your system according to external permissions. In short, this type of system should not depend 100% on third party servers, but they can be complementary.

Social application or game

If your application is a game or has some social character focused on getting as many people as possible, I recommend that you use as many external servers as possible so that you can reach as many users as possible.

Consumer-oriented application by other developers

Let’s say that your application enables was created to be used only by developers. So, I recommend implementing an Oauth server, preferably own to ensure that other developers will not be on hand if an external server (Google, Facebook etc) falls.

Comments on the two questions:

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.

In fact Facebook and Google are widely used as authorization and even authentication servers, it does this in games and in the case of Google between the own systems like Google Drive and Gmail.

The use of Oauth also makes it possible to destroy credentials. If you want to see a practical example of this, modify your Facebook password and it will ask you if you want to quit the other apps. Why does he do this? In fact, if he were to ask a programmer, the question would be: Do you wish to invalidate all tokens being used?

In fact, the important thing about this implementation is that you use tokens instead of user and password. I don’t need to keep giving my password to an unknown system, I can simply give it certain permissions. And this is very visible when Google informs the permissions requested by a particular application, for example.

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.

The use of Oauth 2.0 is similar in many applications, but nothing prevents your server or client that also uses Oauth 2.0 from having its own business rules. Permissions are more associated with what you can do in other people’s systems, for example if you can see the contact list or date of birth, among other things.

Editing

As you modified the question, I will leave my answer as it was and try to clarify some points:

Editing: I may be completely mistaken, but I see this case the Restful API other than the external provider login used on websites, as here in stackoverflow.

The Restful API may or may not be fully disconnected from the system used on the sites, at the discretion of the development team. I can’t tell you how stackoverflow works, but it has its own API, including with Authentication with Oauth 2.0 and is able to consume Google’s, for example.

In the case of a Restful API, there is no user interface.

In REST itself it does not exist, but nothing prevents its application from operating in a hybrid way, implementing interfaces and consuming itself.

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, as the API is communicated after? After all, after logging into the provider, redirecting would lead the user to the client.

Your way of thinking is not incorrect, but there are other ways of implementing Oauth. Of course, the most common way is to click a button and be redirected to another application and then return to yours. But it is not impossible to perform this procedure in back, requesting user and password, creating an interface for user authentication.

In doing so, if you’re starting to use Oauth now, it might complicate your life a bit. The easiest way is to actually use a Basic Authentication or Digest everything will depend on the type of your application, as I mentioned earlier.

Browser other questions tagged api security-guard rest authentication oauth2

You are not signed in. Login or sign up in order to post.