Clever Geek Handbook

What is the correct way to use OAuth for mobile and website using my own API?

I have a question that has more to do with how OAuth 2 works, but since using IdentityServer to implement OAuth, I find it relevant. I couldn't find the answer anywhere.

I am creating a website and mobile app that consumes my own API. Every user of my application will have a username and password that will give them access to the application / website and while API to its information.

I'm not sure about the correct way to handle the user login stream:

  • On the website, I have my own designed login form. I don't want to move the user to my authorization server to login and then ask him to approve the information he gives - he is the user of my system - I have access to all the information - kida for example facebook has login and access to information - they don't ask what you are willing to give them. So what is the implicit way to do this?
  • In the mobile app I also have a login form and now I read here ( https://tools.ietf.org/html/draft-ietf-oauth-native-apps-10 ) that the OAuth approach should have a login in the WebView ? Doesn't look like facebook login is in WebView in its mobile app.
  • The approach I first looked at is resource owner. Users will log in, receive a token and refresh token, and can start working with my APIs. But keeping my client_id and secret in the mobile app? on the website javascript files? doesn't feel good. I can of course call the API, which will disguise them and be the proxy for the login process ... but ... (read # 4).
  • In the future, I would like to allow access to third party developers. In order to allow login for users on my system, I will use an implicit flow. Also, I plan that these developer accounts will have limited access to the API (for example, the number of API calls will be limited by the plan). What prevents developers from prompting for the username and password of their account on my system on their website, receiving a response from my servers with an access token and updating the token and using my API, but they want, without restrictions, and have access to the entire user profile ?
  • Suppose I am following the resource owner flow, getting the token and refresh token back from the server. What should I store on my mobile device and how? What should be stored in the browser and how? refresh token? and every time he opens the app gets a new refreshed token with this refresh token?

Edit

Just to clarify, because I find many lectures and articles that explain the process from the perspective of an API consumer (i.e. a third party developer): I am the owner of the API and the owner of the auth server, m the owner of the user accounts (they are my users of my services ), I am also my own consumer (although this is a website and a mobile app) and in the future I want third party developers to allow my users to log in with their accounts of my service (like Facebook or Google)

+3


source to share


1 answer


It's correct that you shouldn't be storing client_secret

in your application, but I doubt you are done with storing client_id

. You can also turn off the consent screen for your app and create your own login window. You need to store access_token

it refresh_token

on the device as well (possibly encrypted in the database) if you don't want the user to log in every time they use your app.

For issue 4, you can do the following:



  • Paste client_secret

    into your (web) application
  • Configure which hosts have access to your api on IdentityServer
  • IdentityServer generates salt and sends it to client
  • The client computes session_secret

    withhash(ip_address + session_salt)

  • The client uses session_secret

    and client_secret

    to call the API
  • The server checks hash

    andclient_secret

It's almost impossible to completely prevent anyone from using your API. But you have to add various methods of rate limiting like IP limiting, API calls, etc. But nothing will stop your application from decompiling and accessing yours client_id

.

0


source






More articles:


All Articles