Comment by 411111111111111 | Hacker News Reader

Comment by 411111111111111 | Hacker News Reader

Parent Full thread

411111111111111

most of my knowledge about oauth is about using it at my dayjob for years, so don't take my answer with any authority. its more a users perspective of the technology then how it was actually meant to be used, which i do not know.

first off: the whole idea of using oauth in your systems is to externalize authentication. its main usecase is if you have several services which share the same users... usually microservices, but everything else which supports oauth works as well, obviously

if you do not actually want to externalize your authentication, then oauth is likely not what you actually want. (keep in mind this only applies to the process of authentication. you will probably still create a `users` table to put a foreign key on your domain entities. said users table just won't have a `password` field or similar)

under this perspective it makes sense that you basically only find blog posts to integrate 3rd party tools, right? you're just setting out to implement a new oauth2 server otherwise after all, and... i'd strongly suggest you don't. there are so many pitfalls you can fall into. its not a trivial subject.

thankfully, there are readily available FOSS oauth2 servers like keycloak around if thats what you want to use...

but to come back to my initial point: if you do not want to externalize your authentication, then do not use oauth! almost all frameworks already have tools available you can use to authenticate with api tokens. it keeps you within the bounds of your frameworks strength and you can automatically fetch a token on your frontend after the user authenticated with your usual flow.

but i'm already off topic considering your first question. if you do use a solution like keycloak, there are `oauth clients`. these behave exactly as you want.

> first off: the whole idea of using oauth in your systems is to externalize authentication. its main usecase is if you have several services which share the same users... usually microservices, but everything else which supports oauth works as well, obviously

We don't want to externalize it. For clarity _(because i think i implied internal API->API)_, our primary concern right now is a client API interfacing with our API. We want to choose some implementation that clients would expect, and easily reason about.

There may be a future where those clients have to authenticate to multiple APIs / microservices of ours, but currently it is one API setup for this explicit purpose.

> but to come back to my initial point: if you do not want to externalize your authentication, then do not use oauth! almost all frameworks already have tools available you can use to authenticate with api tokens.

Yea, not using Oauth was my thought was well. My concern however, was trying to pick something clients would expect. I don't want it to feel custom, arbitrary, hodgepodge.

Our very early impression / plan is to use a token renewal, and a shortlived token, similar to oauth. However this loose, and custom, and i don't want clients feeling like we're making things up. Hell, i don't want to make things up.

My current thought is that I need to research JWT more, as it may fit what we need, and be more standardized.

edit: And PASETO

You should probably just try out a foss oauth server to get a feel for it.

Just start a keycloak server with docker and write a small Webservice in your language of choice which only let authenticated users open the website, which just prints the user name for example.

After you did that, you could write a second service which accesses that api using a client (not user) and prints which users have accessed it since it was started.

That should be doable within a few hours at most and give you a feel for the technology.

If you're fluent in python, I'd personally suggest just starting a hello world flask project, connect it to a keycloak and write a second cli script which simulates the non-user access. (If you use Java, keep in mind that springboot2 uses Springsecurity5, which was incompatible with the official keycloak Java sdk the last time I checked. Either use springboot1 or expect to have a slightly harder time figuring out what to write in the application.properties)

Reimplementing advanced authentication systems like jwt on your own is extremely error prone and frankly unnecessary if you're not in the business of authenticating users. I'd suggest to either use whatever your framework prefers (which is usually just a static and very long, manually rotated token) or try to externalize it by using readily available foss solutions

> Yea, not using Oauth was my thought was well. My concern however, was trying to pick something clients would expect. I don't want it to feel custom, arbitrary, hodgepodge.

I think clients often expect one of the following (assuming everything is done over HTTPS): 1. HTTP basic auth 2. Login to the API, get a token, and use that token for requests 3. Generate an API key for the client and the client sends the key on every request 4. (Occasionally) Cryptographic signing of every request, sending the signature with the request

1 and 3 (if implemented as a username/password on the back end) are going to have similar trade offs. You are fully authenticating every request that comes in against your credentials data store.

Option 2 is where OIDC/OAuth2 comes into play or you could use a standard session token approach if you want. In OAuth terminology the client credentials grant is the simple flow where the client logs in with a username/password, gets a token back, and includes that token in API calls. Option 2 is also valuable if you want to support mobile clients with refresh tokens and such using things like the authorization code grant. Essentially allowing users to login to a mobile app once but use short-lived tokens when calling the API without prompting users for credentials every few minutes.

Option 4 can be an alternative to token-based approaches to reduce load on your credentials database but gets more complicated for the client.

Ultimately if you are looking to keep things simple I would lean towards HTTP Basic auth until/unless you are building a mobile app or otherwise really need to move to a token-oriented approach. At that point I would consider full fledged OIDC/OAuth2 or maybe a login that generates an API session token.

Reply on news.ycombinator.com