Magento 2 OAuth authentication and REST API access

[eversun]

sorry for posting this question again, but I'm very much want to get the right answer:

Based on the following document, the new OAuth-based authentication doesn't require user to provide a username and password, does that mean any user get the consumer key and secret will able to access the REST API, and don't need user authorization at all? how do I add the user authroization logic during oauth?

http://devdocs.magento.com/guides/v2.0/get-started/authentication/gs-authentication-oauth.html

[akent99]

We don't use OAuth for normal user logins, which confuses people (understandably).  We use OAuth to generate a long life token if you want one computer system to authenticate against Magento - e.g. an ERP system so it can send product or pricing updates to Magento. Yes, if you give that stuff out, whoever you give it to can access your APIs - so protect that information carefully. I think of it kinda like a SSL private key file. Different format, but used in a similar way.

We use a separate API if you want a user to supply a username/password to authenticate (like on a mobile device) which returns a token to include in future request headers. That is, if you have a username and password and want to authenticate requests based on that, read http://devdocs.magento.com/guides/v2.0/get-started/authentication/gs-authentication-token.html instead.

[eversun]

Thanks for your quick response, this is very different from the previous oauth flow, which requires both consumer key+secret and user authentication with better security protection, is there any reason that Magento 2.0 using different way for oAuth? we want to have a combination of consumer key + secret plus username and password to give authentication to a mobile app(basically same as the previous oAuth flow), what is the easy way to customize the new oAuth flow to fit into that?

the old flow:

http://devdocs.magento.com/guides/m1x/api/rest/authentication/oauth_authentication.html#OAuthAuthent...

[Alex Paliarush]

In Magento 1 we follow pure OAuth 1.0a, i.e. application is identified by consumer key/secret. When the end user wants to use 3rd party application to access Magento, they are redirected to authentication endpoint on Magento side to enter credentials, after authentication, access token and token secret is issued and stored in the application. After that each request to API includes consumer key, access token and the whole request is signed with consumer secret and token secret.

In Magento 2 we follow different authentication approaches depending on 3rd party system type:

1. We support only OAuth 2.0 bearer tokens for authentication of users behind 3rd party applications. Access token can be obtained using special endpoints (separate for admin and customer) which accept user name/password
2. OAuth 1.0a style is supported during integration with systems like ERP, which have multiple users on their side as well (during access token/key generation these tokens are associated with the real users on the side or 3rd party system). To initiate token exchange flow, all optional fields should be filled out on Magento side during ‘Integration’ creation in the admin panel.

[Eugene Tulika]

This is how I understood your question: why don’t we use consumer key + secret, when we authenticate consumers through the login and password? So that, let's say, mobile app, will get oAuth tokens first and only after that will allow customers to login.

We debated a lot do we need usage of tokens for the customer login or not. And realized, that the only way for mobile application to get tokens will be to hardcode them inside mobile application. All the users of that mobile application will share same tokens — it does not make it more secure, because it is very easy to reverse engineer sources of mobile app and figure out what tokens does it use.

Otherwise, if it is not hardcoded, user of mobile application will need to obtain tokens first, configure mobile application, and then login — this was not acceptable from user experience standpoint. Same with javascript clients — tokens does not make it more secure in comparison with the regular web ui login form.

As a result, for consumers to log in we use consumer credentials, passed to authentication service. When consumer successfully authenticated, it gets a long-living token which is stored in his mobile application. If token get compromised, it can be revoked from the admin backend.

[akent99]

Thanks @Eugene Tulika. @eversun does that answer you question? (Can you accept the response?) 

[eversun]

well, not really.. with the previous consumer key and secret, it adds additional security check, for example we added custom code to generate dynamic consumer key and secret and assign to each registered user from our mobile app, so it eliminates the access to REST APIs without the correct consumer key and secret. Now with the new token based oAuth, any registered user will have access to the REST API, meaning that we can't simply control access to REST API through oAuth authentication.

[akent99]

We have 3 different auth modes for REST API access. One was designed for mobile - accept a username/password combination. It sounds like you want something in addition to that? Could you provide more details on the use case so I understand better? (Is it you want to use OAuth for the user auth eg via a web browser, then use that Auth against Magento?)

[eversun]

sorry for the late response.. the problem with token based REST API access is that anyone who register through the website will able to access all the resources through a REST client and collect/update all the information easily, we created a bunch of custom REST API code for our mobile app, which we don't want everyone able to access it through REST client, we only allow people who are registered user(with correct username and password), and have correct consumer key and secret able to access resources through the REST API call(which adds additional security for the REST API call).

[akent99]

You can plug in different authentication schemes I believe (I have not tried it, but we support a few and I think you can add more). I assume you know each API can have `<resource>` elements specified - you can have different access rights for different REST APIs based on roles etc.  You can certainly set it up so that not everyone who can log on to the site gets access to the API.  The Admin UI would be in a lot of trouble if that was the case! If you have not seen it, http://devdocs.magento.com/guides/v2.0/get-started/authentication/gs-authentication.html provdies some more information.