5 ms·

Every time I looked at OAuth I found it overly complex for what I wanted to do. Thus, never actually implemented that, maybe I am missing something on that, tho

by cygned 9y ago

Every time I looked at OAuth I found it overly complex for what I wanted to do. Thus, never actually implemented that, maybe I am missing something on that, though. JWT is great until you get to the point where you want to have things like token revocation. A simple session mechanism we use for our apps: - Upon sign in, generate a session token, e.g. 32 characters. Session tokens are unique and fully random, not derived from any actual data - In our scenario, a user can have multiple session at a time. We store two mappings in a Redis database; user-id=>user-object (for caching purposes, serialized JSON) and session-id=>user-id - The second mapping has an expiration time which is the session length eventually, e.g. 30 minutes - Upon every request, we take the session id from the request (header or cookie, cascadingly) and look for the session-id in Redis. If found, we prolong the time to live of that entry. From Redis, we got the user-id (because of the mapping) and thus we can retrieve the cached user object, too. So we have a meaningless token (at least externally), our backend is still stateless (at least the application itself, Redis is stateful in nature) and we don't have to reinvent any wheels for automatically terminating sessions. In addition, it's easy to cancel session on demand and build a blacklist. We wrote the handling ourselves (except for the crypto of course), because no express.js related library/middleware was flexible enough. And eventually we kind of trusted nobody.

deleted 9y ago
[deleted]
Ninn 9y ago
> JWT is great until you get to the point where you want to have things like token revocation. What a flawed argument, there are techniques that allows for session revocation, even in an async stateless jwt context, i.e. By blacklisting, which will work great, and give you some nice properties, depending on your infrastructure and design. Sadly, some appear to assume jwt is some special solution that does X right and y wrong.. but its really nothing other than a structured format in the end. But surely a lot of people do a lot of wrong stuff when deploying their stuff on top of jwt.
- kodablah 9y ago
  Yup, this board is full of JWT hate mostly predicated on the fact that it can be done wrong. Just use a random token as a session ID. Wrap in cookie for browser users and use browser session cookie expiration. Wrap in JWT and sign an expiration date in there for API use...no other state needed, use token to look up actual valuable state on server side as necessary. Expire them server side too based on application re-login requirements to prevent reuse (or sign your cookies w/ an expiration date like you do with JWT...but I always keep session tokens and expire them on the server side too for various reasons including auditing purposes).
  - akvadrako 9y ago
    And what does that give you over just using a cookie?
    - fny 9y ago
      Sometimes you don't have cookies? Like with mobile apps. With JWT you can also have uniform auth across mobile and web apps, and when done right is a beautiful thing™. Also cross domain/app data signing.
      - tatersolid 9y ago
        > Sometimes you don't have cookies? Like with mobile apps. A cookie is just an HTTP header. Any mobile app that can speak HTTP can use cookies.
- cygned 9y ago
  > What a flawed argument, Touché! > session revocation, even in an async stateless jwt context > blacklisting But isn't blacklisting stateful in its nature and thus achieving the opposit of what JWTs are for? Am I missing something obvious?
  - kodablah 9y ago
    JWT's are just special signed formatted strings with a couple of dots in the middle. I only use them for API tokens, and I don't use them statelessly, I just use them so the client knows the format and can check expiration inside it. Sure many use them to pass around signed state, but that's a choice. They're just a container for a stateful session ID for me.
venantius 9y ago
The advantage of OAuth in certain situations is that you can basically get out of being responsible for holding user's credentials entirely. Let's say you're CircleCI or Travis or some other service like that - as long as you can build your product on top of GitHub, you don't actually need to store a user's login credentials yourself. It's still a somewhat complicated flow to have to put together, but your threat model on the other side is lower since you don't have to worry about being a vector for someone to try to steal the user's credentials.
merb 9y ago
well basically OAuth2 Resource Owner Password Credentials Grant (https://tools.ietf.org/html/rfc6749#section-4.3 https://tools.ietf.org/html/rfc6749#section-4.3) Is basically the same thing than Login Form + Cookie, just that you return the Token instead of setting a Cookie. So it's only more complex if you also act as a OAuth Provider, that implements all the other Flows.

by cygned 9y ago

deleted 9y ago

[deleted]

Ninn 9y ago

> JWT is great until you get to the point where you want to have things like token revocation. What a flawed argument, there are techniques that allows for session revocation, even in an async stateless jwt context, i.e. By blacklisting, which will work great, and give you some nice properties, depending on your infrastructure and design. Sadly, some appear to assume jwt is some special solution that does X right and y wrong.. but its really nothing other than a structured format in the end. But surely a lot of people do a lot of wrong stuff when deploying their stuff on top of jwt.

kodablah 9y ago
Yup, this board is full of JWT hate mostly predicated on the fact that it can be done wrong. Just use a random token as a session ID. Wrap in cookie for browser users and use browser session cookie expiration. Wrap in JWT and sign an expiration date in there for API use...no other state needed, use token to look up actual valuable state on server side as necessary. Expire them server side too based on application re-login requirements to prevent reuse (or sign your cookies w/ an expiration date like you do with JWT...but I always keep session tokens and expire them on the server side too for various reasons including auditing purposes).
- akvadrako 9y ago
  And what does that give you over just using a cookie?
  - fny 9y ago
    Sometimes you don't have cookies? Like with mobile apps. With JWT you can also have uniform auth across mobile and web apps, and when done right is a beautiful thing™. Also cross domain/app data signing.
    - tatersolid 9y ago
      > Sometimes you don't have cookies? Like with mobile apps. A cookie is just an HTTP header. Any mobile app that can speak HTTP can use cookies.
cygned 9y ago
> What a flawed argument, Touché! > session revocation, even in an async stateless jwt context > blacklisting But isn't blacklisting stateful in its nature and thus achieving the opposit of what JWTs are for? Am I missing something obvious?
- kodablah 9y ago
  JWT's are just special signed formatted strings with a couple of dots in the middle. I only use them for API tokens, and I don't use them statelessly, I just use them so the client knows the format and can check expiration inside it. Sure many use them to pass around signed state, but that's a choice. They're just a container for a stateful session ID for me.

venantius 9y ago

The advantage of OAuth in certain situations is that you can basically get out of being responsible for holding user's credentials entirely. Let's say you're CircleCI or Travis or some other service like that - as long as you can build your product on top of GitHub, you don't actually need to store a user's login credentials yourself. It's still a somewhat complicated flow to have to put together, but your threat model on the other side is lower since you don't have to worry about being a vector for someone to try to steal the user's credentials.

merb 9y ago

well basically OAuth2 Resource Owner Password Credentials Grant (https://tools.ietf.org/html/rfc6749#section-4.3 https://tools.ietf.org/html/rfc6749#section-4.3) Is basically the same thing than Login Form + Cookie, just that you return the Token instead of setting a Cookie. So it's only more complex if you also act as a OAuth Provider, that implements all the other Flows.