Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nobody Cares About OAuth or OpenID Connect

developer.okta.com

Post reply on HN
Print view View original

111–116 of 116 posts

Re: Nobody Cares About OAuth or OpenID Connect

#111

Post by dwaite »

javier2 wrote: post #78
wvh wrote: post #47

I implemented a minimal OpenID Connect server internally a few years back when it was difficult to find something for our specific use case in Go. I think that while the general idea is good, the spec is a mess: it's too flexible in all the wrong ways, so every large player implements it slightly differently, leaving you with no clear path to go yourself; and actually making the protocol (... concept?) less secure th…

> I think that while the general idea is good, the spec is a mess: it's too flexible in all the wrong ways, so every large player implements it slightly differently, leaving you with no clear path to go yourself This was my experience doing _anything_ at all with OAuth. Now I am seeing the same with OpenID Connect, though not as severe. The spec was narrowed a bit, but it is still way too broad.

I recommend looking at the basic client profile of OIDC to start. It is a good cut through all the options.

Also you may want to look at the OIDC conformance testing tools for testing if you are building your own library or server. Certification costs money, but the conformance testing tools I believe are all open source.

Re: Nobody Cares About OAuth or OpenID Connect

#112

Post by hirsin »

dwaite wrote: post #108
hirsin wrote: post #52

Earlier quoted context omitted.

Look at the JWT, take the issuer claim, take the .well-known config off that url, and you have keys. Match that against the known permanent issuer you expected, and verify the signature of the JWT against the keys. If you're accepting things that aren't JWTs then you're not doing oauth.

Only OpenID Connect has a guarantee that it will issue a JWT token (and only the id_token). OAuth allows access and refresh tokens to be opaque to the client - e.g. either: - a value only the AS understands (in which case the protected resources will need to use an API to introspect them) - a format that both the AS and protected resources can understand (such as a legacy crypto format, a COSE token, or a database ke…

Yes, I misread and typo'd, thinking OP was talking id_tokens and OIDC. Completely correct on the last para, I spend quite a bit of time convincing partners of this.

Re: Nobody Cares About OAuth or OpenID Connect

#113

Post by hirsin »

arkh wrote: post #94
hirsin wrote: post #52

Earlier quoted context omitted.

Look at the JWT, take the issuer claim, take the .well-known config off that url, and you have keys. Match that against the known permanent issuer you expected, and verify the signature of the JWT against the keys. If you're accepting things that aren't JWTs then you're not doing oauth.

> If you're accepting things that aren't JWTs then you're not doing oauth. As a resource server: https://tools.ietf.org/html/rfc6749#page-10 Access tokens don't have to be JWT. And some OpenID authentication server give opaque tokens: your resource server has to know how to call it to check the token and get some user infos if available.

Yes, I misread and typo'd.

Re: Nobody Cares About OAuth or OpenID Connect

#114

Post by SomeHacker44 »

scopendo wrote: post #72
SomeHacker44 wrote: post #49

I recently built an app that outsourced the entirety of the account creation, email validation, MFA and authorization to AWS Cognito and AWS ELB. All I have to do is verify a signed JWT passed in by a header by the ALB (and configure all that stuff and automate it into CloudFormation). Never building this infrastructure again. What a huge time saver. My company used Okta. We ended up cancelling it as it did not seem…

Is that architecture helpful for a saas app that needs to support users from corporate customers using single sign-on via an OIDC or SAML provider like Azure AD or ADFS? I looked into using Okta or Auth0 for this sort of setup, but both were prohibitively expensive for a saas app.

We integrated one third party provider into our AWS Cognito as a test - Google. The idea was to allow many and myriad third party providers to integrate with it, and we wouldn't have to bother to do any of the integration: just configure the Cognito and the other sides, and our app logic does not have to care (but can get that info from the JWT payload if it cares).

Re: Nobody Cares About OAuth or OpenID Connect

#115

Post by SomeHacker44 »

robotdan wrote: post #60
SomeHacker44 wrote: post #49

I recently built an app that outsourced the entirety of the account creation, email validation, MFA and authorization to AWS Cognito and AWS ELB. All I have to do is verify a signed JWT passed in by a header by the ALB (and configure all that stuff and automate it into CloudFormation). Never building this infrastructure again. What a huge time saver. My company used Okta. We ended up cancelling it as it did not seem…

> We ended up cancelling it as it did not seem to offer any value whatsoever and was crazy expensive for our 300-odd users. When you canceled Okta, did you build it in house, or was the AWS Cognito / AWS solution the replacement? Did you look at anything on-prem like Keycloak or FusionAuth?

We did not replace Okta with anything whatsoever.

Re: Nobody Cares About OAuth or OpenID Connect

#116

Post by SomeHacker44 »

chayesfss wrote: post #98
SomeHacker44 wrote: post #49

I recently built an app that outsourced the entirety of the account creation, email validation, MFA and authorization to AWS Cognito and AWS ELB. All I have to do is verify a signed JWT passed in by a header by the ALB (and configure all that stuff and automate it into CloudFormation). Never building this infrastructure again. What a huge time saver. My company used Okta. We ended up cancelling it as it did not seem…

Okta is free for up to 1000 monthly unique users, not sure why it's expensive, just looked at developer.okta.com/pricing

We were paying around $100/user/year for our around 300 users.
Post reply on HN