3 ms·

I'm currently in the middle of implementing an OAuth 2.0 authorization server following the RFC draft of the best current practice [1]. It's been a huge pain n

I'm currently in the middle of implementing an OAuth 2.0 authorization server following the RFC draft of the best current practice [1]. It's been a huge pain navigating all the interlinked (and sometimes contradicting) RFCs around, especially with a distinct lack of resources for actually implementing an authorization server. RFC6749 does not suffice on its own since it says nothing about authentication or tokens payload (not that it should). I did discover the whole RFC universe which are mostly fascinating and very well written. Most google searches end up to Auth0 (nice SEO!), which I'm sure is a fine product, but usually only gives a very high-level overview of the corresponding spec and ends up like "see how this is all complicated? there's a SAAS for that...". I'm seriously considering implementing a fully spec-compliant OAuth 2.0 + OpenID Connect Core 1.0 reference server implementation in Typescript, with full documentation quoted straight from the RFCs. The HOW is actually pretty straight-forward once you've figured out the WHAT and WHY. [1] https://tools.ietf.org/html/draft-ietf-oauth-security-topics https://tools.ietf.org/html/draft-ietf-oauth-security-topics

mehhh 7y ago
I would love to see a reference server implementation for OAuth 2.0 & OpenID Connect Core 1.0, as it would be quite helpful when I go to add OAuth 2.0 to the libre software suite we use at work!
- matdehaast 7y ago
  May be worth checking out https://github.com/ory/hydra https://github.com/ory/hydra and related projects by ory
  - jiripospisil 7y ago
    There's also https://github.com/panva/node-oidc-provider https://github.com/panva/node-oidc-provider for Node.js
sjroot 7y ago
I’m actually working on the same thing but in Rust. If you ever want to compare notes sometime, give me a shout out. I’m actually kind of glad the documentation found via google searches (save one collection of Medium articles) has been disappointing. It has motivated me to look directly at the specification which I’ve found to be the most valuable resource thus far.
- pierreyoda 7y ago
  Oh yeah definitely! Rust would be awesome but I think I'd want it to be as accessible as possible. Tagged unions and proper error handling would make it much saner though that's for sure.
  - sjroot 7y ago
    I was initially going to do it in TypeScript, as the clients that will be interacting with it are TypeScript. Can’t really go wrong either way, but yeah, I’ve enjoyed exploiting Rust’s type system!
    - microcolonel 7y ago
      Be careful to do the hard stuff in workers, otherwise your throughput will be limited by one core. Sorry if that's so basic of a consideration that it's insulting, but I've seen it done before.
- utopian3 7y ago
  Which medium collection? I’d like to read to refresh my knowledge
  - sjroot 7y ago
    https://medium.com/google-cloud/understanding-oauth2-and-building-a-basic-authorization-server-of-your-own-a-beginners-guide-cf7451a16f66 https://medium.com/google-cloud/understanding-oauth2-and-bui...
po 7y ago
IMO, the python oauthlib does a really good job of this. they include the relevant sections of the spec into the function documentation so you can follow along: https://github.com/oauthlib/oauthlib/blob/master/oauthlib/oauth2/rfc6749/grant_types/authorization_code.py https://github.com/oauthlib/oauthlib/blob/master/oauthlib/oa...
spraak 7y ago
> I'm seriously considering implementing a fully spec-compliant OAuth 2.0 + OpenID Connect Core 1.0 reference server implementation in Typescript That'd be awesome - I'd appreciate learning from something like that, and I really appreciate Typescript
cbaleanu 7y ago
Me and my team are happy users of keycloak[0] running in a docker swarm, pretty nice so far anf very good documentation. Building your own authorization/authentication solution is really nice as you learn a lot, but there is a lot of work involved. [0] https://github.com/keycloak/keycloak https://github.com/keycloak/keycloak
rhacker 7y ago
I'd love to see RFCs return back to one goal, one RFC. These days we have RFC ivory towers where they make a base spec, and 7-8 implementation option specs. All separate RFCs. Very horrible. (edit a goal being a complete thing: oauth2)
kevlened 7y ago
This is a great exercise. It's really fulfilling to learn a spec by implementing. I've used @panva's certified [0] js provider [1] and client [2] for many use cases. Is there a reason (aside from learning) to reimplement the spec? If you do, you may consider getting your implementation certified to expand the list! [0] https://openid.net/developers/certified/ https://openid.net/developers/certified/ [1] https://github.com/panva/node-oidc-provider https://github.com/panva/node-oidc-provider [2] https://github.com/panva/node-openid-client https://github.com/panva/node-openid-client

mehhh 7y ago

I would love to see a reference server implementation for OAuth 2.0 & OpenID Connect Core 1.0, as it would be quite helpful when I go to add OAuth 2.0 to the libre software suite we use at work!

matdehaast 7y ago
May be worth checking out https://github.com/ory/hydra https://github.com/ory/hydra and related projects by ory
- jiripospisil 7y ago
  There's also https://github.com/panva/node-oidc-provider https://github.com/panva/node-oidc-provider for Node.js

sjroot 7y ago

I’m actually working on the same thing but in Rust. If you ever want to compare notes sometime, give me a shout out. I’m actually kind of glad the documentation found via google searches (save one collection of Medium articles) has been disappointing. It has motivated me to look directly at the specification which I’ve found to be the most valuable resource thus far.

pierreyoda 7y ago
Oh yeah definitely! Rust would be awesome but I think I'd want it to be as accessible as possible. Tagged unions and proper error handling would make it much saner though that's for sure.
- sjroot 7y ago
  I was initially going to do it in TypeScript, as the clients that will be interacting with it are TypeScript. Can’t really go wrong either way, but yeah, I’ve enjoyed exploiting Rust’s type system!
  - microcolonel 7y ago
    Be careful to do the hard stuff in workers, otherwise your throughput will be limited by one core. Sorry if that's so basic of a consideration that it's insulting, but I've seen it done before.
utopian3 7y ago
Which medium collection? I’d like to read to refresh my knowledge
- sjroot 7y ago
  https://medium.com/google-cloud/understanding-oauth2-and-building-a-basic-authorization-server-of-your-own-a-beginners-guide-cf7451a16f66 https://medium.com/google-cloud/understanding-oauth2-and-bui...

po 7y ago

IMO, the python oauthlib does a really good job of this. they include the relevant sections of the spec into the function documentation so you can follow along: https://github.com/oauthlib/oauthlib/blob/master/oauthlib/oauth2/rfc6749/grant_types/authorization_code.py https://github.com/oauthlib/oauthlib/blob/master/oauthlib/oa...

spraak 7y ago

> I'm seriously considering implementing a fully spec-compliant OAuth 2.0 + OpenID Connect Core 1.0 reference server implementation in Typescript That'd be awesome - I'd appreciate learning from something like that, and I really appreciate Typescript

cbaleanu 7y ago

Me and my team are happy users of keycloak[0] running in a docker swarm, pretty nice so far anf very good documentation. Building your own authorization/authentication solution is really nice as you learn a lot, but there is a lot of work involved. [0] https://github.com/keycloak/keycloak https://github.com/keycloak/keycloak

rhacker 7y ago

I'd love to see RFCs return back to one goal, one RFC. These days we have RFC ivory towers where they make a base spec, and 7-8 implementation option specs. All separate RFCs. Very horrible. (edit a goal being a complete thing: oauth2)

kevlened 7y ago

This is a great exercise. It's really fulfilling to learn a spec by implementing. I've used @panva's certified [0] js provider [1] and client [2] for many use cases. Is there a reason (aside from learning) to reimplement the spec? If you do, you may consider getting your implementation certified to expand the list! [0] https://openid.net/developers/certified/ https://openid.net/developers/certified/ [1] https://github.com/panva/node-oidc-provider https://github.com/panva/node-oidc-provider [2] https://github.com/panva/node-openid-client https://github.com/panva/node-openid-client