1

I need to implement a web-based authentication protocol so users I know can be given access to a third-party web application. I will work with the developers of that web application to implement both sides, since they currently do not support authentication delegation.

At first, I thought I would implement an OpenID 2.0 IdP, since I thing the protocol is simple and well-designed. But the other developer feels concerned that OpenID 2.0 is considered obsolete, and thinks we should rather use the newer OpenID Connect…

Given that we have no need for authorization delegation that OAuth might provide, OpenID Connect looks bloated to me.

So, should I consider it is dangerous to deploy the obsolete OpenID 2.0 now and choose OpenID Connect or should I insist on using the older and simpler OpenID 2.0 protocol?

And if I should choose OpenID Connect, is there a good reason not to use the implicit flow (with “response_mode” set to “query”)? I’d rather avoid the extra server-to-server round-trip that looks useless to me, for a protocol that only provides identity…

Improve this question
4
  • I'm confident that you can find good (as in: well tested) libraries providing OAuth out of the box. I use django-oauth and flask-oauth and am confident in the OAuthLib implementation below them. (But that's the python usage, I do not know which technology stack you use). Arguing that something is bloated is not necessarily a good argument for security. A bloated and well tested app is still better than a minimalistic and untested. (Although smaller attack surface matters if both are well tested).
    – grochmal
    Commented Mar 4, 2017 at 1:02
  • @grochmal I will be using python, but I did not mention it because I thought it was somewhat off-topic. My question is about the protocols.
    – user2233709
    Commented Mar 4, 2017 at 1:47
  • Oh OK, when I head we will work on both sides I understood that both sides will try to roll their own implementations from scratch. My bad. I guess I'd take it from a usability perspective, which actually is an important perspective for security sometimes. Let's try some reasoning.
    – grochmal
    Commented Mar 5, 2017 at 2:09
  • @grochmal No problem. If a side already has an implementation for a protocol, that would be a good reason to use this protocol. That’s why I wrote that we will have to work on both sides. You certainly have an interesting point of view, I’d be happy to upvote your answer, but I don’t have enough reputation… However, you don’t answer the part about the flows (implicit or authorization code), and I’d like to read more arguments, so I’m not going to accept your answer.
    – user2233709
    Commented Mar 6, 2017 at 10:05

1 Answer 1

Reset to default
1

I'll take on this question from the usability and extensibility point of view. For example, if I'm planning to use a protocol to exchange data, say text messages between users, over the network between two applications my first choice would be HTTP.

Why would I choose HTTP instead of something simpler, for example raw TCP with some hand made header on top? Because application grow, and I know that in two months time I'll be extending this simple hand crafted header to add text encoding. In four months time I'll extend the header again to allow for chunked transfer. And in 3 years time I'll end with a horrible to maintain and document hand crafted header that is probably buggy as hell (including security implications).

If I choose to use HTTP, at first it will look bloated. But after 3 years I'll discover that 80% of the extensions I have added are conformant to some part of the HTTP protocol. So I need to document less things, and need to maintain less code myself.

And now back to OpenID 2.0 vs. OpenID Connect.

OpenID Connect is layered on top of OAuth 2.0, OpenID 2.0 isn't. For a long time OpenID was a concurrent system to OAuth, yet, they both have a slightly different philosophy of usage:

  • OpenID is a way to have a single set of credentials to several places.

  • OAuth is a way to access data that is stored in one place from several places.

So yeah, you are looking for a solution in which that users from one place can access another place using the same credentials. You are after OpenID not OAuth.

Yet, it is highly likely that at some point in the future you will want to extend this interaction between the two websites and share not only credentials but also data between the two. If you implement OpenID 2.0 now, you will need to implement OAuth at that point and will have a cranky piece of software in which there are two different types of credentials floating around. And that is quite error prone.

If you go for OpenID Connect, then, when your users will want to share data, you will have the scaffolding already built. All you will need to do is to add extra processing of the valet key and your application is clean.

Of course, it is only likely that at some point in the future the interaction between the websites will need to increase. And to evaluate this likeness is beyond the information that can be written in a discussion of the comparison of the advantages and disadvantages of the two protocols. Yet, I'd certainly prefer having an ace in the hole for when such a situation arrives, rather than risk ending with an ugly and error prone extension.

Improve this answer
1
  • Thanks, that’s an interesting point. Even though I am pretty sure there will be no need to increase the interaction with that third-party application, I should consider that there might be in the future other applications that will user my IdP.
    – user2233709
    Commented Mar 5, 2017 at 10:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .