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

OpenAUTH: Universal, standards-based auth provider

openauth.js.org

Post reply on HN
Print view View original

61–70 of 76 posts

Re: OpenAUTH: Universal, standards-based auth provider

#61

Post by sontek »

Alupis wrote: post #6
reactordev wrote: post #5

Earlier quoted context omitted.

It looks like it’s strictly for OAuth 2.0 flows. No SAML, no ldap, no Kerberos, so it’s just a basic key exchange for those who can’t be bothered. Auth is hard and consumes too much sprint cycles, as is, so anything is welcome in this space. I personally will stick to keycloak.

The people who require SAML, LDAP and Kerberos are often catering towards a specific userbase (ie. internal business customers). The needs for Auth & Auth are different for public-facing apps/services. It's not entirely unsurprising many newer Auth solutions don't even attempt to implement SAML et al. With all of the recent steep price hikes in the Auth SaaS space, it seems it's becoming increasingly important to act…

Most b2b products are going to need SAML auth. Any reasonably sized tech business will want to onboard their employees into the software through SSO and the easiest way to do that is usually SAML if they are using something like Okta or JumpCloud.

Along with that, if they have compliance requirements like SOC2 then they really want the whole flow including offboarding any employees that have left the company.

Re: OpenAUTH: Universal, standards-based auth provider

#62

Post by Alupis »

sontek wrote: post #61
Alupis wrote: post #6

Earlier quoted context omitted.

The people who require SAML, LDAP and Kerberos are often catering towards a specific userbase (ie. internal business customers). The needs for Auth & Auth are different for public-facing apps/services. It's not entirely unsurprising many newer Auth solutions don't even attempt to implement SAML et al. With all of the recent steep price hikes in the Auth SaaS space, it seems it's becoming increasingly important to act…

Most b2b products are going to need SAML auth. Any reasonably sized tech business will want to onboard their employees into the software through SSO and the easiest way to do that is usually SAML if they are using something like Okta or JumpCloud. Along with that, if they have compliance requirements like SOC2 then they really want the whole flow including offboarding any employees that have left the company.

You are describing enterprise, not normal b2b. Majority of businesses out there buying SaaS/PaaS products are not big enterprise with SSO needs nor compliance requirements. The SMB market is huge.

Enterprise types of users are their own beast.

Re: OpenAUTH: Universal, standards-based auth provider

#63

Post by Alupis »

victor106 wrote: post #30
Alupis wrote: post #4

Earlier quoted context omitted.

KV Stores aren't magical... and you do need to store this data somewhere . So what's different between this (or any of these new-aged Auth services) and something else more traditional? If anything, these new-age services make it easier to access your data if you need to, since you often control the backing database unlike auth0, etc. Both DynamoDB and Cloudflare KV are queriable. I guess I don't understand the negat…

> since you often control the backing database unlike auth0, etc. Auth0 has an option where you can use your own database for identities

Starting at $240 a month...

Re: OpenAUTH: Universal, standards-based auth provider

#64

Post by afiori »

pixl97 wrote: post #39
Alupis wrote: post #11

Earlier quoted context omitted.

Eh, the technology stack they discuss is directly accessible, though. I read this as an advertisement, meaning if everything it working well you don't need to manage the database. Which is probably how it works 99% of the time in fairness.

99% of the time is a rather high rate of failure .. 1% of a year is still over 3 days. 1% of a million is still a lot of incidents

Sure but you are allowed to put the 99% front and center in marketing.

A good chunk of the other 1% are square-peg-in-round-home situations.

It is good to support all the various edge cases but it is also on 6 to focus on the happy path

Re: OpenAUTH: Universal, standards-based auth provider

#65

Post by afiori »

ash wrote: post #19

Cool project! OAuth-based auth providers are nice, but they can have a weakness. When you have just one app, OAuth can be overkill: protocol is complex, and users suffer jarring redirects¹. This is not surprising, because OAuth / OIDC is fundamentally designed for (at least) three parties that don't fully trust each other: user, account provider and an app². But in a single app there are only two parties: user and ap…

My personal gripe with OAuth is that the simple case can be implemented with like 2 redirects and 2 curls, but docs are often incomprehensibly complicated by dozens of layers of abstractions, services, extensions, enterprise account management and such.

Re: OpenAUTH: Universal, standards-based auth provider

#66

Post by apitman »

Trying to understand where this fits in to the current ecosystem. Looks like it's sort of like Passport but it runs in a separate server, and apps use OAuth2 to communicate with it? The example video looks like it's only doing authentication. Does it do any authorization? Do apps need to use OpenAuth libraries directly, or can they get back with basic cookies/redirects/etc?

Re: OpenAUTH: Universal, standards-based auth provider

#67

Post by unscaled »

swiftcoder wrote: post #50
michaelt wrote: post #48

Earlier quoted context omitted.

> we do, in fact, have secure implementations of SAML. Do we? I thought we only had implementations where with no currently known security problems.

> no currently known security problems To be fair, that is the layman's definition of "secure"

Yes, that was my usage of "secure" here. I obviously didn't mean that we should blindly trust SAML implementations. SAML should be avoided if possible, due to inherently complicated implementation. The same goes true for JWT. Both standards have better alternatives which are viable for the majority of necessary use cases.

Re: OpenAUTH: Universal, standards-based auth provider

#68

Post by unscaled »

thdxr wrote: post #56
unscaled wrote: post #31

Earlier quoted context omitted.

- JWT algorithm is not configurable: good! - JWT Algorithm is RS512: uggh. Huge access tokens, slow validation AND bad security at the same time, boy we must be lucky. - Encrypted JWT when saving sensitive information in cookie? Good start... - ... Using Asymmetric encryption? Oh no... - RSA-OAEP: At least it's not PKCS#1.5 amirite? - Same RSA key is used for encryption and signature(?) Not great. - Stateful Access T…

thanks for writing this up! i have been looking at switching to PASETO instead of jwt one thing though - the reason we use asymmetric encryption is to allow other clients to validate tokens without calling a central server eg if you use AWS API Gateway they specifically have jwt authorization support where you can point them to a jwks url and it will validate requests i need to look into the algorithm again - another…

> thanks for writing this up! i have been looking at switching to PASETO instead of jwt

I'm glad to hear that! PASETO would solve all the cryptography issues I've described above.

> one thing though - the reason we use asymmetric encryption is to allow other clients to validate tokens without calling a central server

There seem to be two different usages of asymmetric JWT in OpenAUTH:

1. Asymmetric RSA signatures for access tokens. These tokens can be validated by any third party server which supports JWT. The tokens are SIGNED, but not ENCRYPTED. If you did encrypt them, then third party servers will not be able to verify the token without having the private key — which is obviously insecure.

This type of token would usually be asymmetric if you want to support multiple audiences ("resource servers" in OAuth 2.0 terms) with the same token. If you have just one audience, I would still make this token symmetric, unless key distribution is a problem. AWS JWT authorizer sucks[1], but you could write your own lambda authorizer. Google Cloud (Apigee)[2] and Azure API Management[3] natively support HS256/384/512, so this is mostly an AWS problem.

2. Asymmetric signature AND encryption for cookies. I guess these cookies are used for saving SSO state and PKCE verifier, but I didn't dive deeply into that. This cookie seems to be only read and written by the OpenAUTH server, so there is no reason for using asymmetric encryption, let alone using it with the same RSA keypair for both encryption and signature[4].

Since the cookie is only read by OpenAUTH, you can just use PASETO v4.local for this cookie.

---

[1] I wouldn't trust the security of a product which ONLY allows RSA, when they could have enabled safer protocols with a single line of code.

[2] https://cloud.google.com/apigee/docs/api-platform/security/o...

[3] https://learn.microsoft.com/en-us/azure/api-management/valid...

[4] https://crypto.stackexchange.com/questions/12090/using-the-s...

Re: OpenAUTH: Universal, standards-based auth provider

#69

Post by lstamour »

portaouflop wrote: post #46
lstamour wrote: post #37

Earlier quoted context omitted.

It's fair to say that with OAuth the resource owner can choose to display a consent screen or not. For example, when consent is granted already, it can be skipped if the resource owner does not need it. Likewise, Google Workspace and other enterprise services that use OAuth can configure in advance which apps are trusted and thus skip permission grants. Not to say the concern about redirects isn't legitimate, but the…

> Even redirects aren't necessary if OAuth is implemented in a browser-less or embedded browser fashion, e.g. SFAuthenticationSession Can you please expand on that or give me some hints what to look at? I have never heard of this before and I work with Oauth2 a lot. When I look for SFAuthenticationSession it seems to be specific to Safari and also deprecated. I always share this article because people overimplement O…

For browserless, I was referring to a 2019 article that I could have sworn was newer than that, on the need for OAuth 2.1 that also covers how they added OAuth for Native Apps (Code Flow) and basically a QR code version for TVs: https://aaronparecki.com/2019/12/12/21/its-time-for-oauth-2-...

As for SFAuthenticationSession, again my info might be outdated, but the basic idea is that there are often native APIs that can load OAuth requests in a way that doesn’t require you to relogin. Honestly most of those use cases have been deprecated by PassKeys at an operating system level. There’s (almost) no need for a special browser with cookies to your favourite authenticated services if you have PassKeys to make logging in more painless.

Re: OpenAUTH: Universal, standards-based auth provider

#70

Post by portaouflop »

lstamour wrote: post #69
portaouflop wrote: post #46

Earlier quoted context omitted.

> Even redirects aren't necessary if OAuth is implemented in a browser-less or embedded browser fashion, e.g. SFAuthenticationSession Can you please expand on that or give me some hints what to look at? I have never heard of this before and I work with Oauth2 a lot. When I look for SFAuthenticationSession it seems to be specific to Safari and also deprecated. I always share this article because people overimplement O…

For browserless, I was referring to a 2019 article that I could have sworn was newer than that, on the need for OAuth 2.1 that also covers how they added OAuth for Native Apps (Code Flow) and basically a QR code version for TVs: https://aaronparecki.com/2019/12/12/21/its-time-for-oauth-2-... As for SFAuthenticationSession, again my info might be outdated, but the basic idea is that there are often native APIs that ca…

Thanks for sharing!

I agree that passkeys would solve all that, but they have their own set of problems (mainly being bound to a device) and they are still very far from being universally adopted.

I’m looking forward to OAuth2.1 - at the moment it is still in draft stage, so it will take a couple more years until it’s done and providers start implementing.

My prediction is that passwords will be around for a long time, at least the next 10 years.

Post reply on HN