2

I'm building an OAuth 2.0 server for a mobile (native) application and website using IdentityServer. I wondering about the correct flow that I should use in the mobile application and the website.

As far as I know the "implicit" flow is pretty much what I'm getting when registering as a developer for external API (such as Facebook) and when a user logs in to my website using his Facebook account he is referred to a Facebook login page that directs him with the token back to my website. This seems secure to me since the auth server refers the user to a callback url (at least for websites).

What I implemented so far is the "Resource Owner" flow, which validates user credentials against the server with client_id and it's password. The problem as I see it is that the client_id and password are stored on the app (and can be reversed engineered) or on the website javascript code.

I read on this post (What's the right OAuth 2.0 flow for a mobile app) that it's better to create on my API a method for logging in, and my API will communicate against the auth server (and so the client_id and password will only be stored on it).

I'm wondering about how companies like Facebook or Google do that. They have their own login on the website, and they give API access to third party developers - what prevents developers making some authentication to their users against the Facebook login and using their APIs without limitations?

  1. What is the correct method of working? Implicit? RO?
  2. After user loges in to the website or app - how should he be remembered as logged in? Do I save the refresh token on the app/website side?
Community
  • 1
  • 1
developer82
  • 13,237
  • 21
  • 88
  • 153
  • What do you want the OAuth2 server for? Just authentication? Do you also have a backend? If yes, do you want to have it stateless or keep a session there for logged users? – Ján Halaša Apr 27 '17 at 14:06
  • I need OAuth2 for authentication of users in web and mobile. There is also a stateless backend. – developer82 Apr 27 '17 at 14:29
  • You won't like the answer - but this is the way to go: https://tools.ietf.org/html/draft-ietf-oauth-native-apps-10 – leastprivilege Apr 28 '17 at 06:12
  • @leastprivilege So what you're telling me is that Facebook login in their app is done in a webview? doesn't look like it. And doesn't look like they are using the implicit flow since they obviously don't need to ask user permission to information. – developer82 Apr 29 '17 at 05:14

1 Answers1

0

I would use the Implicit flow, because as you mentioned, you cannot keep your password secure in your applications.

Since your backend is stateless, you will need to send a token (ID token or access token) with each request. Flows handled by a backend (e.g. Auth Code grant) don't fit a stateless API.

If you want just authentication of users, I guess your backend handles access rights on its own and does not rely on access token scopes. Then I would use the OpenID Connect (OAuth2 extension) - requesting just the openid scope to get an ID token. The ID token guarantees the user's identity and the backend doesn't have to verify it's validity at the OAuth2 server.

If you want to configure permissions for your users at the OAuth2 server, your frontend applications will need to get an access token. The backend can then read scopes of the access token.

When keeping a token in your frontend applications, they will need to watch token validity periods and ask for new token before the current one expires. You can do it at the /auth endpoint (with prompt=none URL parameter). For more info you can check OpenID Connect Session Management.

With OAuth2, it's important to keep in mind that it's about permission delegation. Taking Google as an example, they provide an OAuth2 server and application that rely on access tokens issued by it. So if a third party application wants to use Google Plus on behalf of the user, the application must request the user to give it permissions (access token scopes) for accessing Google Plus. The user can review the list of requested scopes at the consent page and the application will not be permitted to do anything else. It's up to user to consider how much he trusts the application. For more info see OAuth2 spec.

Community
  • 1
  • 1
Ján Halaša
  • 8,167
  • 1
  • 36
  • 36
  • Thanks. But as I understand the implicit flow will not use my app login screen - it will open a browser with a login screen - and since it's my app and my backend I would like them to input the username and password inside the app login screen. Also, doesn't implicit work with refresh tokens? – developer82 Apr 28 '17 at 03:46
  • How can I make sure no one abuses my APIs somehow? – developer82 Apr 28 '17 at 08:26
  • Only applications (clients) you allow may use your OAuth2 server, so if your API receives a token issued by your OAuth2 server, it can trust it. – Ján Halaša Apr 28 '17 at 08:33
  • I know that. But what I'm afraid of is that someone will take the call my website or mobile app and send it to the server - receiving the token that belongs for the client_id that I'm using for my apps and he will have access to all APIs without restrictions that I put for third-party developers. – developer82 Apr 28 '17 at 09:06
  • Do you mean some attacker will get a token? It can only happen if you don't secure your communication (https) or the applications don't handle it properly or a user makes it public. First two problems are your concern and the last one is improbable - the user would willingly harm himself. – Ján Halaša Apr 28 '17 at 09:28
  • No. I mean third-party developers. Let say I decide to give API for developer with restricted access or restricted number of API calls by their client_id. To override this restriction they will prompt users for their credentials on a form they create, and invoke the exact same call I make from my website to login, and get back the token for the user, and use the API without any restriction - as if they were my app. – developer82 Apr 28 '17 at 13:30
  • The authentication request to OAuth2 server contains a `client_id` and a `redirect_uri` that must be registered for the client. So if some rogue application makes an auth call with another application's client_id and redirect_uri, it will not get the tokens, because the user will be redirected to the provided redirect_uri - the application you approved (your webapp). – Ján Halaša Apr 28 '17 at 14:06
  • And for mobile? currently my mobile app users the Resource Owner flow so it only supplies the client_id and password along with username and password of the user - and as a response gets the token in the server body response as json object. – developer82 Apr 28 '17 at 18:06
  • I tried making my question a little more detailed here: http://stackoverflow.com/questions/43689218/what-is-the-correct-way-to-use-oauth-for-mobile-and-website-consuming-my-own-api – developer82 Apr 28 '17 at 21:35
  • I am confused about some details... Could you please have a look? Thanks! link ---> https://stackoverflow.com/q/61313694/4619958 – ch271828n Apr 20 '20 at 01:06