
A guide to securing client-side apps (mobile, native, browser) with OAuth2 - 0xff00ff00
https://www.ory.sh/oauth2-for-mobile-app-spa-browser?branch=master
======
dang
We've banned this site and associated accounts for what looks like serious
abuse of HN's voting and flagging systems. That is not ok here.

------
BillinghamJ
Nice to see PKCE included, though no mention of the state param. Also not a
great experience to log in via a web browser, and not really more secure given
a malicious app could just fake a browser. Magic links with PKCE + app-site
association would be better.

Some tips:

1\. Don't build your own OAuth 2 server.

And if you're just doing auth for your own apps - not providing auth services
for third parties to integrate with - I wouldn't suggest using OAuth at all.
It's much more complicated and you're much more likely to make mistakes.

It isn't a bad idea to (carefully) read and learn from the principles of the
OAuth 2 spec in order to make your own auth services, but I'd generally
suggest avoiding making an OAuth server by hand unless you are very
experienced in doing this. There are a lot of silly mistakes you can make due
to the over-complication.

2\. Don't use passwords.

It's 2018. Passwords are really not a good way to secure your system. You're
going to end up building an email-based password reset system anyway right? So
just cut to the chase and use magic-link based login only. It's pretty easy to
do securely.

3\. Keep it simple.

If you're implementing something you don't fully understand, or think you
probably understand, but haven't considered every possibility, you're likely
to introduce vulnerabilities. A simple auth protocol which you fully
understand will perform better than a complex one you don't understand.

~~~
arekkas
Couldn't agree more with these points. I'd like to point out that

> It isn't a bad idea to read and learn from the OAuth 2 spec in order to make
> your own auth services

has actually lead to quite horrible auth systems. I've seen bad stuff in large
enterprises due to this ("we're smarter, we'll solve it for our use case" ->
"Oops, we didn't think about session replay").

I recommend OAuth2 for complex systems with many involved parties and clients.
There it can really reduce complexity. For normal apps with maybe 1-2
consumers, cookie-based security is secure and good enough!

~~~
BillinghamJ
Hmm yes, good point. Have slightly adjusted the post.

Assuming you have _fully_ read and understood the OAuth spec, I find that it
can be a helpful resource to identify the more complex considerations that
might be easily missed in a home-grown auth implementation.

That being said, in my company's case, I haven't entirely followed my own
advice, and we did implement our own OAuth 2 server. But we do know the spec
pretty comprehensively.

Edit: if anyone's interested in our particular flavour of the protocol, we
have it documented at
[https://github.com/cuvva/docs/blob/master/apis/auth.md#send_...](https://github.com/cuvva/docs/blob/master/apis/auth.md#send_authorization_code)

