Reputation: 1041
I have a first party mobile app which consumes my own REST API.
I’m wondering what the common practice is for implementing authentication.
OAuth2 seems to be widely used, but I’m not sure if it’s the right choice, because I don’t want to redirect users to a login web page (which I don’t even have) and show them a consent screen. It just seems silly asking “do you allow EvilCorp iOS App to access your EvilCorp account?”. Is there an OAuth flow type which matches these requirements?
Currently I’m rolling my own setup. I don’t have a dedicated authentication server (but I’m 100% cool with building one). I have a /signin
endpoint in my API, which is protected with HTTP Basic Authentication, and returns a token (JWT). The /signup
endpoint returns a token too. Other endpoints are mostly protected with HTTP Bearer Authentication and validate this token.
It works, but I would much rather follow a widely accepted protocol and use conventional libraries, than to try to reinvent the wheel. What is the conventional method I should use?
Upvotes: 3
Views: 649
Reputation: 29218
The OAuth 2 family of technologies are a framework for providing the best modern architecture options for data protection, authentication and integration with other systems:
It is very common to use OAuth without user consent - most apps from companies work like this. Consent tends to only come into play when the user's personal assets are involved.
The OAuth standard for mobile apps is the AppAuth Pattern. However, there is a learning curve you have to overcome, and this involves externalising the login user experience and storage of user accounts, which can be tricky.
So no quick answer here, but it is worth exploring an architecture where you no longer store credentials or write code to issue tokens, and where you have more future facing security capablities:
Upvotes: 1