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?
Nobody Cares About OAuth or OpenID Connect
91–100 of 116 posts
Re: Nobody Cares About OAuth or OpenID Connect
#92Earlier quoted context omitted.
> don’t know what you do if Facebook decides your a robot and suddenly 50,000 people can’t authenticate to your site This is exactly why I am paranoid about depending entirely on social sign up/in. So if the API provides it, I believe it's a good idea to capture the email address associated with the social account and either generate a hard password for later reset if necessary or request the user set one up. The lat…
> Authentication is just too important to completely outsource without recourse I agree 100%. You need to own your users and all of their data. Along those same lines, I wouldn't want my user data going into a multi-tenant, cloud-hosted solution like Okta. I'd much prefer to store everything on my own servers or use an on-premise solution like FusionAuth or KeyCloak.
https://news.ycombinator.com/user?id=brokenwren
I see what you did there. :)
Good luck.
Re: Nobody Cares About OAuth or OpenID Connect
#93The redeeming feature about OAUTH, like pretty much anything security related, is that if you don’t give people a standard to follow then you are probably going to end up with something that is insecure and poorly implemented. A lot of people just don’t have the background to do good security work, and when you try to explain why a short lived credential is good, or why we can’t have a plain text password embedded in…
Re: Nobody Cares About OAuth or OpenID Connect
#94Earlier quoted context omitted.
And a problem for the Resource Server: no common way to check the validity of a token. You may be lucky and get a JWT but even then there's no specified URL to get the keys to check it. Usually you get an opaque token and hope the client gives you a way to know where it comes from so you can do some specific server to server call. So you can't implement an independant RS which does not care about clients and how they…
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.
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.
Re: Nobody Cares About OAuth or OpenID Connect
#95Earlier quoted context omitted.
And a problem for the Resource Server: no common way to check the validity of a token. You may be lucky and get a JWT but even then there's no specified URL to get the keys to check it. Usually you get an opaque token and hope the client gives you a way to know where it comes from so you can do some specific server to server call. So you can't implement an independant RS which does not care about clients and how they…
That's what the Introspection endpoint should be for.
When you get a token you are not sure to get it as a JWT. If it is a JWT, the issuer is not enough to know what endpoints it provides.
You still have to care about your clients authorization provider so you can check their access tokens. But you're building a resource server: you should not have to care about all this. Creating a resource with this identity from this issuer? Go ahead. Want to access it again? Let me check your token using this standardized token: I don't have to know if is issued by Google, the Canadian Government or your own personal server.
Re: Nobody Cares About OAuth or OpenID Connect
#96Our web services are all running under the same base domain reactos.org and we wanted a Single Sign-On system for all of them. I was surprised to find out that doing this simple seems to be an unresolved problem: CAS, OpenID Connect, and SAML all want you to set up heavyweight authentication servers and a certificate infrastructure for identifying each participating web service. A lot of protocol messages need to travel for a simple action like a user login when a site-wide session cookie could just do the same job. Sure, those systems support advanced features like access control and delegated authentication, but this is all not required if you just want to link a few web services under your own control, say a MediaWiki and phpBB forums.
RosLogin simply sets a site-wide session cookie on each user login. Each web service then just calls RosLogin::isLoggedIn() to check its validity and retrieve the user name. No certificates, no protocol messages, and no heavyweight server software is involved. Together with centralized Login, Registration, and Self-Service pages, RosLogin currently needs no more than 1600 lines of PHP code - perfectly auditable from a security standpoint!
The ReactOS infrastructure is mostly built around PHP web services, so PHP bindings and plugins for Drupal, MediaWiki, and phpBB are currently the only ones available for RosLogin. However, our few non-PHP services can still plug into the same user database by connecting to RosLogin's underlying OpenLDAP directory.
Re: Nobody Cares About OAuth or OpenID Connect
#97The author of this article cannot be trusted. He regularly writes articles that compare non-best practices of JWT to best practices of other technologies to make JWT look bad. Because of him, I would not trust Okta at all. Take any article by Okta with a grain of salt.
Re: Nobody Cares About OAuth or OpenID Connect
#98I 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…
Re: Nobody Cares About OAuth or OpenID Connect
#99Earlier quoted context omitted.
> Authentication is just too important to completely outsource without recourse I agree 100%. You need to own your users and all of their data. Along those same lines, I wouldn't want my user data going into a multi-tenant, cloud-hosted solution like Okta. I'd much prefer to store everything on my own servers or use an on-premise solution like FusionAuth or KeyCloak.
> ...use an on-premise solution like FusionAuth or... https://news.ycombinator.com/user?id=brokenwren I see what you did there. :) Good luck.
Re: Nobody Cares About OAuth or OpenID Connect
#100I 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