7 ms·

OAuth vs. SAML vs. OpenID Connect

123 points by willow9886 10y ago

philips 10y ago
> If you are writing a new application, use OpenID Connect–skate to where the puck is going! I am glad to see this advice. At CoreOS we have now built API servers, command line tools, and web apps using OpenID Connect and are happy with its development in Open Source and third-party services as well. > OAuth2 was left generic so that it could be applied to many authorization requirements, When we started developing Dex[1] we lovingly referred to OpenID as "OAUTH 2.0 with types". Overall, from integrating OpenID Connect into our products, enabling Kubernetes[2] to use OpenID Connect Providers, and building both an OpenID Connect provider and clients we are pretty happy with the choice we made. My only complaint is the name of OpenID Connect is simply confusing. [1] https://github.com/coreos/dex https://github.com/coreos/dex [2] http://kubernetes.io/docs/admin/authentication/#openid-connect-tokens http://kubernetes.io/docs/admin/authentication/#openid-conne...
- willow9886 10y ago
  > My only complaint is the name of OpenID Connect is simply confusing. Yea..many people only remember the failed OpenID 1 & 2 specs...so, out-of-the-box there is some developer fatigue associated with Connect. However, federation standards have proven to be pretty sticky--SAML was written 10+ years ago. Hopefully as Connect continues to be developed, marketed, and implemented by developers, it will over shadow previous unsuccessful versions of the protocol.
  - philips 10y ago
    I have just started saying OIDC as that has no fatigue attached to it. And then if people want clarification I explain the whole silly naming story.
  - user5994461 10y ago
    Don't confuse OpenID and OpenID Connect. They are very different things.
    - pyvpx 10y ago
      with very similar names?
      - user5994461 10y ago
        They shouldn't have had similar names. This is causing a lot of confusion ^^
        nailer 10y ago
        OpenID has a bad enough reputation amongst developers - with the user being asked to remember bizarre URLs - that I'm surprised they kept the name.
  - idm_guru 10y ago
    It's no more confusing then LDAP. First there was LDAP 1.0, 2.0, now we all use 3.0... OpenID 2.0 is deprecated. Don't use it. The current OpenID authentication protocol = OpenID Connect. In the not too distant future, no one will even remember that something called OpenID 2.0 existed. Maybe OpenID Connect should be OpenID 3.0? I think the idea was to show alignment with Facebook Connect's design...but more open. Remember, at the time Facebook Connect provided some good data--it was a massive user acceptance test. IMHO, the blame lies with the OIDF for not delivering this message. OpenID Connect has been final for 4+ years. What's taking so long? Maybe it's not in the interest of the OIDF's controlling board members to promote this distributed identity infrastructure? MSFT wants you to use Azure AD. Google wants you to use their IDP. Maybe they don't want to promote until they have product ready? Stay tuned... I think when it's in the interest of the current finanical backers of the OIDF to promote OpenID Connect, no one will remember that old OpenID 2.0 thing.
  - WorldMaker 10y ago
    There's also a flipside too: those of us that remember the original community grassroots spirit and attempted simplicity of early OpenID and feel like OpenID Connect misses a lot of the old point of OpenID, and definitely a lot of the intended simplicity.
- philips 10y ago
  And as if to prove my point LWN just ran an article on OpenID https://lwn.net/SubscriberLink/708151/d5cbd707d352d881/ https://lwn.net/SubscriberLink/708151/d5cbd707d352d881/
  - willow9886 10y ago
    This is maddening! OpenID Connect is not an extension of OpenID 1 & 2--it is basically a complete re-write!
- spangry 10y ago
  When I did a short 6 month stint at the Australian version of the GDS (the 'Digital Transformation Office', or DTO), my team stood up a prototype/demo of an attributes-based 'digital identity' system using OIDC. It's almost ideal for the government use-case: private sector IDCs can offer identity/attribute verification services if the government provides an assurance and audit framework. The potential number of digital commercial transactions this could enable are mind-boggling. It's also privacy-preserving due to its attributes-based approach to access control and its federated nature. Also likely to result in a competitive market for IDCs instead of YAGM (yet another government monopoly) due to the low (technical) barrier to entry: I'm a terrible programmer and I spent less time coding a mock RP/client implementation straight from the spec than I did searching around for pre-canned libraries (which didn't seem to exist at the time). It's a shame no-one would listen to us. From what I hear, they're going with some kind of centralised RBAC system. Boy it's going to be fun when some welfare payment or tax concession eligibility criteria is tweaked, forcing them to audit and update roles for 10-15 million people :)
fusiongyro 10y ago
Interesting. I have used CAS extensively and was involved in building SAML support for a commercial app at one time. I didn't understand the post-binding thing really at all--CAS mostly uses the back channel method. My experience with SAML was that, not only was it a bear to get set up, the second client who wanted to use it was using a different SAML implementation and found things weren't as standardized as we had assumed. Both implementations supplied a principal, only one supplied an email address by default. I think it got sorted out after I left. I don't love CAS a lot, but it is a lot more turnkey than SAML. We're investigating JWT now, but I have a feeling it will turn out to be an implementation detail within a larger solution that we haven't even begun to conceive. I've also implemented shitty poor-man's federation on top of CAS. My recommendation there would be: don't do it. If you need federation CAS really can't help you, don't hack on it. The other thing I've learned is that none of these things is going to help you with authentication at all, and that tends to be something that isn't well thought-out before implementation time comes.
- user5994461 10y ago
  JWT = Json Web Token. That's not an authentication protocol at all. It's about using authentication tokens and JSON, which everyone's been already doing for years. SAML = Security & Authentication Mega cLusterfuck. It does get the job done, but it is the hell of a beast to understand and use.
  - chris_wot 10y ago
    I just don't think it's documented all that well. Aside from Wikipedia, where on earth do go to learn how the drafted thing is meant to work? It seems to have multiple profiles, and I can't find a decent article about SAML artifacts anywhere...
    - user5994461 10y ago
      You can get the SAML spec, it's a standard distributed by oasis, last I checked. It will help you a bit. Then you will only have two majors issues. 1) The protocol is a really complex beast of giant XML messages, with many variants of workflows. 2) It's very modular to allow to interface with lots of stuff with custom authentication, custom attributes, custom systems. So there is only 50% of a protocol which is clearly "standardized", the other 50% are left as a specific use case details with limited practical example. I'm a believer that one doesn't do or understand SAML. It's more like, you get two specific products that needs to authenticate together for the business. You read the integration documentation for both and try to find whatever micro-subset of protocol they both talk and make it interface.
spydum 10y ago
Great write up. Dealing with my own employer and the constant confusion around oauth vs OIDC vs JWT, and having to explain they aren't VS at all! They are all stacked on oauth itself, and don't really have much to say about the actual authentication of a user (that is just up to the identity provider).
- willow9886 10y ago
  True, perhaps worth noting though that in OpenID Connect an RP (website or app) can actually request a specific authentication mechanism using the acr_value (assuming the OP supports multiple authentication mechanisms). This can give the application some input over how people are identified before authorizing access to protected resources. http://openid.net/specs/openid-connect-core-1_0.html#acrSemantics http://openid.net/specs/openid-connect-core-1_0.html#acrSema...
- spangry 10y ago
  I think this is one of the great virtues of OAuth/OIDC. It makes you realise that, in most cases, you don't care about identity per se when making access control decisions. We just tend to use it as a proxy to infer attributes...
vittore 10y ago
Anyone here knows of solid FOSS alternatives to gluu? Is there is something that is close to okta functionality-wise?
- willow9886 10y ago
  > that is close to okta functionality-wise? The power of OKTA lies in its thousands of pre-configured SSO relationships. It's important to remember that each one was set up manually with a unique client ID and secret, metadata file, etc. Application integration is the most difficult part of most identity and access management projects. That is why outsourcing identity to a SaaS provider like OKTA or OneLogin is so appealing--they have done all the hard work for you. There are no open source projects like OKTA because if you're using open source software, you will inevitably have to integrate and test each application you want configured for SSO.
  - vittore 10y ago
    Thank you. Keeping those thousands of predefined integrations aside, do you know of any good combination of user-management/access-management/federated-access system beside GLUU?
    - willow9886 10y ago
      ForgeRock has a pretty comprehensive suite of open source IAM software [1] but you have to buy a subscription before you can put it into production. There's also the open source KeyCloak project from RedHat. [2] Also I believe Connect2ID is FOSS. [3] [1] https://www.forgerock.com/ https://www.forgerock.com/ [2] http://www.keycloak.org/ http://www.keycloak.org/ [3] http://connect2id.com/ http://connect2id.com/
      - cyberpunk 10y ago
        You don't, actually, but you need to build it yourself instead of using their binaries (it's OSS). Friends don't let friends OpenAM though, don't bother with WSO2 either. I'd do everything possible to make this someone else's problem, and if you absolutely have to do it in house then ping's the easiest I've worked with thus far.
clintonb 10y ago
The problem with OIDC (from my point of view) is the lack of good libraries for Python/Django projects. We ended up building our own atop the now-defunct django-oauth2-provider. Unfortunately, no one (myself and my company included) has committed to adding the functionality to the more-popular django-oauth-toolkit. This has lead to our questioning the need for OIDC given that we can generate JWTs as access tokens. If the identity info is embedded in the access token, there is no need for the ID token and (more importantly) micro-services no longer need to check in with the authentication provider to validate bearer tokens. I do like the discovery aspects of the OIDC protocol that make it easy to distribute public keys.
- po 10y ago
  Ah... so that must have been you on this issue: https://github.com/evonove/django-oauth-toolkit/issues/110 https://github.com/evonove/django-oauth-toolkit/issues/110 I think the main reason for that is that its not a simple thing to do and there's just not enough expertise out there.
  - clintonb 10y ago
    Yes, that is me. I have the expertise, having maintained a fork of django-oauth2-provider for over a year; however, the issue with django-oauth-toolkit seems to be the lack of responsiveness on the part of the maintainers. We at edX are willing to contribute these features; but, we'd prefer not to maintain a long-term fork of the project.
- ownagefool 10y ago
  We deal with supporting a range of languages by dropping a go proxy infront of the app. https://github.com/gambol99/keycloak-proxy https://github.com/gambol99/keycloak-proxy
- spangry 10y ago
  There's also Hydra, which looks pretty easy to deploy (fyi: I haven't used it): https://github.com/ory-am/hydra https://github.com/ory-am/hydra).
- 10y ago
intrasight 10y ago
I'm a fan of auth0 since it can glue all that identity stuff together.
tscs37 10y ago
I was a bit skeptical when I first heard about OpenID Connect, especially considering the failures of the first OpenID protocols. I'm still looking for a decent OpenID server to run, but dex seems to be good enough. I hope OIC catches on, I'd love some proper identity federation.
chris_wot 10y ago
SAML is freaking hard to setup, and even worse to troubleshoot.
koliber 10y ago
I can only speak to OAuth and SAML. I've done many integrations of each. OAuth is a bit easier to understand. SAML is tougher to grasp. I think it is a terminology and flexibility thing. It seems like each vendor or implementation is using their own terms for the same things. SAML has many super configurable levers, but in reality people tend to use only one or two common variants. SAML is nice that it does not require a direct access between the backends of the client system (SP, or service provider) and the identity provider. All data flows through the web browser. As long as the web browser can access the identity provider (often on a private network) and the client system, it can work. As far as different people implementing SAML in different ways, it is absolutely true. Getting two systems to work together takes real effort. I've had similar, albeit less fatiguing, issues integrating OAuth. One system has exact redirect URLs; others have partial matching some; some require the redirect URL in each call, others in some; and then there's the case where human intervention is required to deliver data that would normally be sent to the redirect URL (Looking at you AWeber!). At least in the OAuth world, people call a duck a duck and it is usually clear what is being referred to. I'm by no means an expert in SAML (like with general relativity, I think there are only five people in the world that truly understand SAML), but have a good working practical grasp of the technology.
- _nat 10y ago
  OIDC can act just like SAML. It can contain the attributes (we call it claims) as well. You do not need a backend call at all if you use implicit flow.
misja111 10y ago
When I try to open the link, it gives me the error "Error opening database connection"
- willow9886 10y ago
  Sorry! DB crashed. It's back up. Thanks for alerting!
scwoodal 10y ago
Having recently been apart of a new SAML implementation, avoid it if you can. The technology behind it feels solid (passing signed/encrypted messages around) and using an Identity Provider like Active Directory is an easy choice but after that is where things get difficult. The client support, at least in Python, is terrible and the resources to understand SAML are sparse. Everyone does something just a little bit different and there isn't much choice. We have some Django applications that needed to be SAML aware. While I was able to finally able to make it work after two weeks (yikes!!) most of my problems resulted in bugs within the client. SAML requests can have more than one signing/encryption certificate defined so when one certificate gets close to expiring you can add a second (or third...), let the first one expire then well behaved clients would automatically use the second one. Except when your client always grabs the first one and if the signing fails because the Idp signed the message with the other certificate and it doesn't try the second one =( Then debugging errors is cumbersome. Always pasting XML snippets and x509 certificates into tools to view the actual messages. Google'ing the error messages with little to nothing out there. Perhaps it's just a bad experience with a specific python module but given the complexity of SAML, little knowledge out there, I'd stick with CAS if given the choice. It might help the technology if whoever is behind it would maintain clients that adhere to the spec.
- deleted 10y ago
  [deleted]
jensakrom 10y ago
amazing dude...
jensakrom 10y ago
amazing dude...
jensakrom 10y ago
amazing dude...
jensakrom 10y ago
amazing dude...
djedipus 10y ago
In defense of SAML for enterprise customers. I built an enterprise site that needed SSO to work for a number of different enterprises. I tried 3rd party solutions, ping fedeate, Auth0, Azure etc. and these were nightmares to configure and get working. Turns out it was way easier just to read the SAML RFC and handle the tokens myself. SAML 2.0 is finally old enough that most enterprises support it. So for me Enterprise SSO is a solved problem. For others having a hard time finding 3rd party plugins / services etc. I highly recommend whipping out the RFC and DIYing a solution. Only took me a couple of days. Far less than what I spent on other solutions.
willow9886 10y ago
Thanks for all the upvotes everyone! If you'd like to connect with the author of the blog, Mike Schwartz, feel free to do so on LinkedIn: https://www.linkedin.com/in/nynymike https://www.linkedin.com/in/nynymike
willow9886 10y ago
There's been some discussion regarding the merits of using JWT's (JSON Web Tokens) instead of Connect. Mike added some clarification in the form of a comment on the blog. I also added it here [1]. Feel free to join the discussion on the blog.[2] [1] https://news.ycombinator.com/item?id=13134752 https://news.ycombinator.com/item?id=13134752 [2] https://www.gluu.org/blog/oauth-vs-saml-vs-openid-connect/#comment-3042980417 https://www.gluu.org/blog/oauth-vs-saml-vs-openid-connect/#c...
- willow9886 10y ago
  New blog published on this topic specifically: http://gluu.co/jwt-not-authn http://gluu.co/jwt-not-authn

123 points by willow9886 10y ago

> If you are writing a new application, use OpenID Connect–skate to where the puck is going! I am glad to see this advice. At CoreOS we have now built API servers, command line tools, and web apps using OpenID Connect and are happy with its development in Open Source and third-party services as well. > OAuth2 was left generic so that it could be applied to many authorization requirements, When we started developing Dex[1] we lovingly referred to OpenID as "OAUTH 2.0 with types". Overall, from integrating OpenID Connect into our products, enabling Kubernetes[2] to use OpenID Connect Providers, and building both an OpenID Connect provider and clients we are pretty happy with the choice we made. My only complaint is the name of OpenID Connect is simply confusing. [1] https://github.com/coreos/dex https://github.com/coreos/dex [2] http://kubernetes.io/docs/admin/authentication/#openid-connect-tokens http://kubernetes.io/docs/admin/authentication/#openid-conne...

willow9886 10y ago
> My only complaint is the name of OpenID Connect is simply confusing. Yea..many people only remember the failed OpenID 1 & 2 specs...so, out-of-the-box there is some developer fatigue associated with Connect. However, federation standards have proven to be pretty sticky--SAML was written 10+ years ago. Hopefully as Connect continues to be developed, marketed, and implemented by developers, it will over shadow previous unsuccessful versions of the protocol.
- philips 10y ago
  I have just started saying OIDC as that has no fatigue attached to it. And then if people want clarification I explain the whole silly naming story.
- user5994461 10y ago
  Don't confuse OpenID and OpenID Connect. They are very different things.
  - pyvpx 10y ago
    with very similar names?
    - user5994461 10y ago
      They shouldn't have had similar names. This is causing a lot of confusion ^^
      - nailer 10y ago
        OpenID has a bad enough reputation amongst developers - with the user being asked to remember bizarre URLs - that I'm surprised they kept the name.
- idm_guru 10y ago
  It's no more confusing then LDAP. First there was LDAP 1.0, 2.0, now we all use 3.0... OpenID 2.0 is deprecated. Don't use it. The current OpenID authentication protocol = OpenID Connect. In the not too distant future, no one will even remember that something called OpenID 2.0 existed. Maybe OpenID Connect should be OpenID 3.0? I think the idea was to show alignment with Facebook Connect's design...but more open. Remember, at the time Facebook Connect provided some good data--it was a massive user acceptance test. IMHO, the blame lies with the OIDF for not delivering this message. OpenID Connect has been final for 4+ years. What's taking so long? Maybe it's not in the interest of the OIDF's controlling board members to promote this distributed identity infrastructure? MSFT wants you to use Azure AD. Google wants you to use their IDP. Maybe they don't want to promote until they have product ready? Stay tuned... I think when it's in the interest of the current finanical backers of the OIDF to promote OpenID Connect, no one will remember that old OpenID 2.0 thing.
- WorldMaker 10y ago
  There's also a flipside too: those of us that remember the original community grassroots spirit and attempted simplicity of early OpenID and feel like OpenID Connect misses a lot of the old point of OpenID, and definitely a lot of the intended simplicity.
philips 10y ago
And as if to prove my point LWN just ran an article on OpenID https://lwn.net/SubscriberLink/708151/d5cbd707d352d881/ https://lwn.net/SubscriberLink/708151/d5cbd707d352d881/
- willow9886 10y ago
  This is maddening! OpenID Connect is not an extension of OpenID 1 & 2--it is basically a complete re-write!
spangry 10y ago
When I did a short 6 month stint at the Australian version of the GDS (the 'Digital Transformation Office', or DTO), my team stood up a prototype/demo of an attributes-based 'digital identity' system using OIDC. It's almost ideal for the government use-case: private sector IDCs can offer identity/attribute verification services if the government provides an assurance and audit framework. The potential number of digital commercial transactions this could enable are mind-boggling. It's also privacy-preserving due to its attributes-based approach to access control and its federated nature. Also likely to result in a competitive market for IDCs instead of YAGM (yet another government monopoly) due to the low (technical) barrier to entry: I'm a terrible programmer and I spent less time coding a mock RP/client implementation straight from the spec than I did searching around for pre-canned libraries (which didn't seem to exist at the time). It's a shame no-one would listen to us. From what I hear, they're going with some kind of centralised RBAC system. Boy it's going to be fun when some welfare payment or tax concession eligibility criteria is tweaked, forcing them to audit and update roles for 10-15 million people :)

fusiongyro 10y ago

Interesting. I have used CAS extensively and was involved in building SAML support for a commercial app at one time. I didn't understand the post-binding thing really at all--CAS mostly uses the back channel method. My experience with SAML was that, not only was it a bear to get set up, the second client who wanted to use it was using a different SAML implementation and found things weren't as standardized as we had assumed. Both implementations supplied a principal, only one supplied an email address by default. I think it got sorted out after I left. I don't love CAS a lot, but it is a lot more turnkey than SAML. We're investigating JWT now, but I have a feeling it will turn out to be an implementation detail within a larger solution that we haven't even begun to conceive. I've also implemented shitty poor-man's federation on top of CAS. My recommendation there would be: don't do it. If you need federation CAS really can't help you, don't hack on it. The other thing I've learned is that none of these things is going to help you with authentication at all, and that tends to be something that isn't well thought-out before implementation time comes.

user5994461 10y ago
JWT = Json Web Token. That's not an authentication protocol at all. It's about using authentication tokens and JSON, which everyone's been already doing for years. SAML = Security & Authentication Mega cLusterfuck. It does get the job done, but it is the hell of a beast to understand and use.
- chris_wot 10y ago
  I just don't think it's documented all that well. Aside from Wikipedia, where on earth do go to learn how the drafted thing is meant to work? It seems to have multiple profiles, and I can't find a decent article about SAML artifacts anywhere...
  - user5994461 10y ago
    You can get the SAML spec, it's a standard distributed by oasis, last I checked. It will help you a bit. Then you will only have two majors issues. 1) The protocol is a really complex beast of giant XML messages, with many variants of workflows. 2) It's very modular to allow to interface with lots of stuff with custom authentication, custom attributes, custom systems. So there is only 50% of a protocol which is clearly "standardized", the other 50% are left as a specific use case details with limited practical example. I'm a believer that one doesn't do or understand SAML. It's more like, you get two specific products that needs to authenticate together for the business. You read the integration documentation for both and try to find whatever micro-subset of protocol they both talk and make it interface.

spydum 10y ago

Great write up. Dealing with my own employer and the constant confusion around oauth vs OIDC vs JWT, and having to explain they aren't VS at all! They are all stacked on oauth itself, and don't really have much to say about the actual authentication of a user (that is just up to the identity provider).

willow9886 10y ago
True, perhaps worth noting though that in OpenID Connect an RP (website or app) can actually request a specific authentication mechanism using the acr_value (assuming the OP supports multiple authentication mechanisms). This can give the application some input over how people are identified before authorizing access to protected resources. http://openid.net/specs/openid-connect-core-1_0.html#acrSemantics http://openid.net/specs/openid-connect-core-1_0.html#acrSema...
spangry 10y ago
I think this is one of the great virtues of OAuth/OIDC. It makes you realise that, in most cases, you don't care about identity per se when making access control decisions. We just tend to use it as a proxy to infer attributes...

vittore 10y ago

Anyone here knows of solid FOSS alternatives to gluu? Is there is something that is close to okta functionality-wise?

willow9886 10y ago
> that is close to okta functionality-wise? The power of OKTA lies in its thousands of pre-configured SSO relationships. It's important to remember that each one was set up manually with a unique client ID and secret, metadata file, etc. Application integration is the most difficult part of most identity and access management projects. That is why outsourcing identity to a SaaS provider like OKTA or OneLogin is so appealing--they have done all the hard work for you. There are no open source projects like OKTA because if you're using open source software, you will inevitably have to integrate and test each application you want configured for SSO.
- vittore 10y ago
  Thank you. Keeping those thousands of predefined integrations aside, do you know of any good combination of user-management/access-management/federated-access system beside GLUU?
  - willow9886 10y ago
    ForgeRock has a pretty comprehensive suite of open source IAM software [1] but you have to buy a subscription before you can put it into production. There's also the open source KeyCloak project from RedHat. [2] Also I believe Connect2ID is FOSS. [3] [1] https://www.forgerock.com/ https://www.forgerock.com/ [2] http://www.keycloak.org/ http://www.keycloak.org/ [3] http://connect2id.com/ http://connect2id.com/
    - cyberpunk 10y ago
      You don't, actually, but you need to build it yourself instead of using their binaries (it's OSS). Friends don't let friends OpenAM though, don't bother with WSO2 either. I'd do everything possible to make this someone else's problem, and if you absolutely have to do it in house then ping's the easiest I've worked with thus far.

clintonb 10y ago

The problem with OIDC (from my point of view) is the lack of good libraries for Python/Django projects. We ended up building our own atop the now-defunct django-oauth2-provider. Unfortunately, no one (myself and my company included) has committed to adding the functionality to the more-popular django-oauth-toolkit. This has lead to our questioning the need for OIDC given that we can generate JWTs as access tokens. If the identity info is embedded in the access token, there is no need for the ID token and (more importantly) micro-services no longer need to check in with the authentication provider to validate bearer tokens. I do like the discovery aspects of the OIDC protocol that make it easy to distribute public keys.

po 10y ago
Ah... so that must have been you on this issue: https://github.com/evonove/django-oauth-toolkit/issues/110 https://github.com/evonove/django-oauth-toolkit/issues/110 I think the main reason for that is that its not a simple thing to do and there's just not enough expertise out there.
- clintonb 10y ago
  Yes, that is me. I have the expertise, having maintained a fork of django-oauth2-provider for over a year; however, the issue with django-oauth-toolkit seems to be the lack of responsiveness on the part of the maintainers. We at edX are willing to contribute these features; but, we'd prefer not to maintain a long-term fork of the project.
ownagefool 10y ago
We deal with supporting a range of languages by dropping a go proxy infront of the app. https://github.com/gambol99/keycloak-proxy https://github.com/gambol99/keycloak-proxy
spangry 10y ago
There's also Hydra, which looks pretty easy to deploy (fyi: I haven't used it): https://github.com/ory-am/hydra https://github.com/ory-am/hydra).
10y ago

intrasight 10y ago

I'm a fan of auth0 since it can glue all that identity stuff together.

tscs37 10y ago

I was a bit skeptical when I first heard about OpenID Connect, especially considering the failures of the first OpenID protocols. I'm still looking for a decent OpenID server to run, but dex seems to be good enough. I hope OIC catches on, I'd love some proper identity federation.

chris_wot 10y ago

SAML is freaking hard to setup, and even worse to troubleshoot.

koliber 10y ago

I can only speak to OAuth and SAML. I've done many integrations of each. OAuth is a bit easier to understand. SAML is tougher to grasp. I think it is a terminology and flexibility thing. It seems like each vendor or implementation is using their own terms for the same things. SAML has many super configurable levers, but in reality people tend to use only one or two common variants. SAML is nice that it does not require a direct access between the backends of the client system (SP, or service provider) and the identity provider. All data flows through the web browser. As long as the web browser can access the identity provider (often on a private network) and the client system, it can work. As far as different people implementing SAML in different ways, it is absolutely true. Getting two systems to work together takes real effort. I've had similar, albeit less fatiguing, issues integrating OAuth. One system has exact redirect URLs; others have partial matching some; some require the redirect URL in each call, others in some; and then there's the case where human intervention is required to deliver data that would normally be sent to the redirect URL (Looking at you AWeber!). At least in the OAuth world, people call a duck a duck and it is usually clear what is being referred to. I'm by no means an expert in SAML (like with general relativity, I think there are only five people in the world that truly understand SAML), but have a good working practical grasp of the technology.

_nat 10y ago
OIDC can act just like SAML. It can contain the attributes (we call it claims) as well. You do not need a backend call at all if you use implicit flow.

misja111 10y ago

When I try to open the link, it gives me the error "Error opening database connection"

willow9886 10y ago
Sorry! DB crashed. It's back up. Thanks for alerting!

scwoodal 10y ago

Having recently been apart of a new SAML implementation, avoid it if you can. The technology behind it feels solid (passing signed/encrypted messages around) and using an Identity Provider like Active Directory is an easy choice but after that is where things get difficult. The client support, at least in Python, is terrible and the resources to understand SAML are sparse. Everyone does something just a little bit different and there isn't much choice. We have some Django applications that needed to be SAML aware. While I was able to finally able to make it work after two weeks (yikes!!) most of my problems resulted in bugs within the client. SAML requests can have more than one signing/encryption certificate defined so when one certificate gets close to expiring you can add a second (or third...), let the first one expire then well behaved clients would automatically use the second one. Except when your client always grabs the first one and if the signing fails because the Idp signed the message with the other certificate and it doesn't try the second one =( Then debugging errors is cumbersome. Always pasting XML snippets and x509 certificates into tools to view the actual messages. Google'ing the error messages with little to nothing out there. Perhaps it's just a bad experience with a specific python module but given the complexity of SAML, little knowledge out there, I'd stick with CAS if given the choice. It might help the technology if whoever is behind it would maintain clients that adhere to the spec.

deleted 10y ago
[deleted]

jensakrom 10y ago

amazing dude...

jensakrom 10y ago

amazing dude...

jensakrom 10y ago

amazing dude...

jensakrom 10y ago

amazing dude...

djedipus 10y ago

In defense of SAML for enterprise customers. I built an enterprise site that needed SSO to work for a number of different enterprises. I tried 3rd party solutions, ping fedeate, Auth0, Azure etc. and these were nightmares to configure and get working. Turns out it was way easier just to read the SAML RFC and handle the tokens myself. SAML 2.0 is finally old enough that most enterprises support it. So for me Enterprise SSO is a solved problem. For others having a hard time finding 3rd party plugins / services etc. I highly recommend whipping out the RFC and DIYing a solution. Only took me a couple of days. Far less than what I spent on other solutions.

willow9886 10y ago

Thanks for all the upvotes everyone! If you'd like to connect with the author of the blog, Mike Schwartz, feel free to do so on LinkedIn: https://www.linkedin.com/in/nynymike https://www.linkedin.com/in/nynymike

willow9886 10y ago

There's been some discussion regarding the merits of using JWT's (JSON Web Tokens) instead of Connect. Mike added some clarification in the form of a comment on the blog. I also added it here [1]. Feel free to join the discussion on the blog.[2] [1] https://news.ycombinator.com/item?id=13134752 https://news.ycombinator.com/item?id=13134752 [2] https://www.gluu.org/blog/oauth-vs-saml-vs-openid-connect/#comment-3042980417 https://www.gluu.org/blog/oauth-vs-saml-vs-openid-connect/#c...

willow9886 10y ago
New blog published on this topic specifically: http://gluu.co/jwt-not-authn http://gluu.co/jwt-not-authn