I find the hardest part about authentication is that somebody will use a method, and then somebody else will tell you that that method is incredibly insecure.
Like, lots of people do stuff others deem "incredibly insecure". It can be really hard to settle on any understanding of what appropriate levels of security are in this space.
Services and top libraries tend to give some direction, but any time you want to change your approach or try something new, you're met with a lot of competing beliefs.
Something that took a while for me to get, and I think I see some of that in your query, is the difference between authentication and authorization.
Authentication: How the system trusts you are who you say you are (OAuth, user/pass, federation, saml, 2factor, etc)
Authorization: What are you allowed to do (Roles, rules, permissions)
These two concepts are often built together but benefit from being treated independently.
Authentication would give you an identity, and whatever rules you've built in your software would allow or prohibit that identity from doing various things.
Or another way. Dev.To knows who you are because of how you log in (Delegated or user/pass). But the fact that you can edit only your own profile and not mine, is what your identity is authorized to do.
Not sure if this is close to helpful, but its what I'll offer.
It definitely helps! And yes, bridging the gap between authentication and authorization has been a sticking point. I can totally understand how to do local username/password authentication and pair it with authorization... but once we get into Identity/Authentication as a Service, I haven't been able to make the mental connection.
I think I'm with you. I'd bring the whole auth service thing back to trust in this case.
Let me put this on a spectrum. What we're talking about is trusting that someone is who they claim they are.
Radio button that chooses between admin and non-admin
A list of users that they choose from
A magic user name, email, or key that they have to enter
User/Pass combination
Log-In Service (eg: Google. Your service is known to google, and tells your service, "Hey, I know who this person is, here")
At the end of the day each one of these makes a claim about who they are. Each one (Hopefully) instills more trust than the one before.
When you use something like Auth0, or Google, or Github to log in, you're essentially saying, "Look, I trust that you solved this problem of knowing who people claim they are, so you tell me who they are and I'll consider that good"
The mechanics of this often obfuscate this, because there's a lot of back and forth. That's part of the dance of trust. Each step in the mechanisms exists to prohibit untrusted sources from getting through.
I find the hardest part about authentication is that somebody will use a method, and then somebody else will tell you that that method is incredibly insecure.
Like, lots of people do stuff others deem "incredibly insecure". It can be really hard to settle on any understanding of what appropriate levels of security are in this space.
Services and top libraries tend to give some direction, but any time you want to change your approach or try something new, you're met with a lot of competing beliefs.
I'll throw something in.
Something that took a while for me to get, and I think I see some of that in your query, is the difference between authentication and authorization.
Authentication: How the system trusts you are who you say you are (OAuth, user/pass, federation, saml, 2factor, etc)
Authorization: What are you allowed to do (Roles, rules, permissions)
These two concepts are often built together but benefit from being treated independently.
Authentication would give you an identity, and whatever rules you've built in your software would allow or prohibit that identity from doing various things.
Or another way. Dev.To knows who you are because of how you log in (Delegated or user/pass). But the fact that you can edit only your own profile and not mine, is what your identity is authorized to do.
Not sure if this is close to helpful, but its what I'll offer.
It definitely helps! And yes, bridging the gap between authentication and authorization has been a sticking point. I can totally understand how to do local username/password authentication and pair it with authorization... but once we get into Identity/Authentication as a Service, I haven't been able to make the mental connection.
I think I'm with you. I'd bring the whole auth service thing back to trust in this case.
Let me put this on a spectrum. What we're talking about is trusting that someone is who they claim they are.
At the end of the day each one of these makes a claim about who they are. Each one (Hopefully) instills more trust than the one before.
When you use something like Auth0, or Google, or Github to log in, you're essentially saying, "Look, I trust that you solved this problem of knowing who people claim they are, so you tell me who they are and I'll consider that good"
The mechanics of this often obfuscate this, because there's a lot of back and forth. That's part of the dance of trust. Each step in the mechanisms exists to prohibit untrusted sources from getting through.
Excellent! That's enough of a good start to give me the confidence to try and implement something this weekend. Thanks!
Keep at it. You'll knock it out in no time. When you do you'll seem like you're a wizard to everyone.