|
|
|
|
|
|
by quelltext
2549 days ago
|
|
|
I'm not too familiar with this space, so please excuse my question. What is OAuth2 server is? I was under the impression that for a given service/API typically OAuth2 is implemented by the provider on their servers, either from scratch or using some sort of library. With an OAuth2 server are you running a separate server or is it an internal service that your application code connects to (and forwards requests?) when OAuth related requests come in? A diagram of how an OAuth2 server fits into an application architecture and a visualization of an OAuth flow in it would greatly help here. |
|
|
OAuth 1.0/2.0 are a set of protocols and standards allowing applications to identify users and get access to their data using existing profiles. OAuth is mostly focused around authorization with claims (which are just key-value pairs) and authentication was an afterthought.
OpenID is another standard designed to let people authenticate across the web, launched with a lot of hype in the early web 2.0 days but never took off. OpenID Connect (OIDC) is a new standard based on OAuth 2 + OpenID to provide both authentication and authorization in a single flow.
OIDC/OAuth is all based on tokens, which are usually JWTs containing a bunch of claims that can be validated against the server that issued them. There are ID tokens (for the user info) and Access tokens (for accessing an API on behalf of that user), but some services like social logins don't provide any access tokens. Other providers might have rate limits, or dont have fine-grained permissions, or you maybe you have completely internal APIs that you need tokens for.
A token/identity server like Hydra can take care of creating and managing all the tokens and grants, and all the OAuth token flows, in a central location between internal and external APIs and user providers.
It's really just a webapp with endpoints that implement all the protocols so you can run it as a service somewhere. Once you do, your apps can then just call the token endpoint to recognize users and your APIs can use it to validate incoming requests which have JWTs. You still need the logic in your code to use OIDC sign-in and/or JWT validation but this is standard functionality and easily available in every stack.