Re:Authlib: Python Authentication
by mooreds on Monday June 26, 2023 @12:48PM
(#36482269)
Full disclosure, I work for an auth server vendor.
So there are three primary use cases for OAuth (I'll include OIDC as well, as they are often paired and OIDC is built on top of OAuth).
* Authentication. Using OIDC for authentication lets you use one of many authentication servers (FusionAuth [my employer], Keycloak, Python OAuthlib, Django with https://django-oidc-provider.readthedocs.io/en/latest/ Auth0, Cognito, etc etc). Using such an identity server lets you have one single place to store user data. It's normalizing user data, which has the same benefits and tradeoffs as normalizing any other kind of data.
* First party API authentication (where the same org controls both the end client and the API server). This is comparable to API keys, but has some differences. Setup is more complicated, but you have credentials that are automatically time bound (tokens expire), support multiple useful flows, and have a refresh mechanism built in. Plenty of security experts have banged on OIDC/OAuth and helped fix issues, and j random developer you just hired is probably more familiar with OAuth than your custom API key scheme. You also have the ability to put more data in the token (if you use JWTs) and have the tokens verified without contacting a central server. This can lead to some nice scaling properties.
* Third party API access. When you are the client and want access to third party APIs, you have to use what the API dictates. That is often either OAuth or API keys. OAuth here has a lot of flavors. See this article which was on HN a month or two ago: https://www.nango.dev/blog/why-is-oauth-still-hard
Source: I work for FusionAuth, an auth provider which supports OAuth and OIDC, and help support users and customers implementing FusionAuth.
So there are three primary use cases for OAuth (I'll include OIDC as well, as they are often paired and OIDC is built on top of OAuth).
* Authentication. Using OIDC for authentication lets you use one of many authentication servers (FusionAuth [my employer], Keycloak, Python OAuthlib, Django with https://django-oidc-provider.readthedocs.io/en/latest/ Auth0, Cognito, etc etc). Using such an identity server lets you have one single place to store user data. It's normalizing user data, which has the same benefits and tradeoffs as normalizing any other kind of data.
* First party API authentication (where the same org controls both the end client and the API server). This is comparable to API keys, but has some differences. Setup is more complicated, but you have credentials that are automatically time bound (tokens expire), support multiple useful flows, and have a refresh mechanism built in. Plenty of security experts have banged on OIDC/OAuth and helped fix issues, and j random developer you just hired is probably more familiar with OAuth than your custom API key scheme. You also have the ability to put more data in the token (if you use JWTs) and have the tokens verified without contacting a central server. This can lead to some nice scaling properties.
* Third party API access. When you are the client and want access to third party APIs, you have to use what the API dictates. That is often either OAuth or API keys. OAuth here has a lot of flavors. See this article which was on HN a month or two ago: https://www.nango.dev/blog/why-is-oauth-still-hard
Source: I work for FusionAuth, an auth provider which supports OAuth and OIDC, and help support users and customers implementing FusionAuth.