12

I have implemented an OAuth 1.0a provider and have OAuth clients that can successfully authenticate against it, using the standard 3-legged authentication.

OAuth protects a REST API on my server and I have a mobile app consuming it.

In my mobile app, I have some functionalities (endpoints) that can be accessible even before the end-user logins to their private account.
Some user may even just want to use the public functionalities without creating an account.

I would like to protect with OAuth both "public" and "private-to-the-user" endpoints.

Therefore I think the way to go is to use OAuth the following way (but I may be wrong...very wrong).

The mobile app will first do 2-legged authentication as soon as the app is launched the first time. That way the mobile app will get a "2-legged" token. The mobile app will use this token to access public endpoints.

When (and if) the user requests to login to the application, the mobile app will do a 3-legged authentication and will get a "3-legged token". From now on, the app will forget about the previous 2-legged token and use the 3-legged token to access both public and private endpoints.

1) First question. Does that make sense? Is there another good way to do that?

Now my problem is: how can I (the server provider) know whether the mobile app wants to authenticate using 2-legged? I guess, as the provider, I need to know that in order to decide whether I will redirect the client to the login form for the user to fill (in the case of 3-legged) or I will just issue an already-authorised request token (in the case of 2-legged) so that that can be exchanged for an access token (as for the 3-legged).

My idea for doing that was to provide the client with 2 consumer keys: one to use when they want 2-legged and one to use when they want 3-legged. Me, as a provider, I will know which flow to provide based on the consumer key I receive.

2) Second (and last question). Is this sensible? Is there a better way to implement it?

I have seen people implementing 2-legged by just allowing the client (consumer) to send an empty access token. Is that the way, instead?

Thanks.

4

1 回答 1

8

OAuth 旨在管理第三方应用程序对您的 REST API 的访问。例如，其他一些公司开发了一个使用您的 API 的应用程序。而且您不希望您的客户向第三方提供这些服务的密码。在这种情况下，OAuth 是解决方案。如果没有第三方应用程序，则不需要 OAuth。

如果您有单一服务并且只有您的应用程序在使用它，那么您不需要实施任何 OAuth。您需要创建通常的用户/密码登录（并且可能正确检查）机制。

使用 HTTPS 足以保护端点交互。如果您想保护移动应用程序或其他一些 REST 消费者上的商店内容，那么您必须在保存之前对其进行加密。

更新：如果你想保护“端点”，那么 3-legged OAuth 是解决方案。2-legged 解决方案需要将第三方应用程序 + 您的 OAuth 应用程序（或 lib）安装到用户设备。否则用户可能会被类似的 UI 伪造，而只是提供一些第三方用户和密码。

于 2013-08-22T22:15:51.237 回答