[Openid-specs-ab] "Nobody Cares About OAuth or OpenID Connect"...

n-sakimura n-sakimura at nri.co.jp
Thu Jan 24 16:28:07 UTC 2019


Maybe we can create Open OpenID RP Award?

Outlook for iOS<https://aka.ms/o0ukef> を入手

________________________________
差出人: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> (George Fletcher via Openid-specs-ab <openid-specs-ab at lists.openid.net> の代理)
送信日時: 金曜日, 1月 25, 2019 1:11 午前
宛先: Artifact Binding/Connect Working Group; Tom Jones
Cc: George Fletcher; Mike Schwartz
件名: Re: [Openid-specs-ab] "Nobody Cares About OAuth or OpenID Connect"...

Outside of the "click-bait" title to get us standards wonks to react... I think the article makes some good points. Today, the "standards" landscape is rather large and knowing how to navigate it to develop a secure and reliable implementation takes a lot of research and expertise. It also leaves a lot of room open for people to do things differently. That is greate as the "swiss army knife of specs" allows many different situations to be solved. However, that doesn't help the general developer trying to do something "simple" (e.g. restrict access to my API - a simple 2-legged OAuth2 use case).

For example, I believe that a secure and reasonable implementation of Dynamic Client Registration for mobile/desktop apps requires using both the OIDC spec and the OAuth2 spec. That means I need to understand both and know how to merge them. This is just one very simple concrete example.

The Security Best Practices doc helps but it's yet another doc a developer has to read and understand before even starting an implementation.

That said, I also feel that adoption of OIDC by open source and commercial tools is generally lacking. I've seen many open source projects have an authentication/authorization plugin for Google (which is really OIDC) but not have a generic OIDC module allowing you to connect that tool to a different OIDC provider. If there is an area of effort, I think it should be encouraging/helping open source and commercial tools consider OIDC/OAuth2 a MUST for their business in the same way that they consider SAML a MUST for their business.

Thanks,
George

On 1/24/19 2:31 AM, Mike Schwartz via Openid-specs-ab wrote:

There is no IAM silver bullet--we are facing a range of security threats and transaction values, and thus a range of appropriate security mitigations.

Of course developers want easier. There's nothing wrong with that. I think Auth0 does a nice job here--offering the Auth0 API which (not telling developers to read a bunch of difficult-to-comprehend specs and profiles). It's also why Gluu introced the oxd middleware--to offer high level API's that do some of the heavy lifting for developers.

Of course we should strive to improve... that's essential. But a good plan today is better than a perfect plan tomorrow.

>From a marketing perspective, this community should be making a stronger case for the technology. You don't see the big data community or the AI community disparaging their technology stack in this manner. And likely those technologies are farther away from their end goals.

I remember a great ad for Sprint mobile phone service, back in the 90's. The ad said "It's a like a land-line... with a really long cord". Nothing was further from the truth. Cell phone service was abysmal. But from a marketing perspective, if Sprint said "Cell phone service sucks. You get lots of dropped calls. Your mom will sound like a robot. And it's expensive too!" ... it wouldn't have helped their cause. It's our job to put forward the positive, not to bolster the case of the detractors.

I know the other side... I spend hours a day talking about federated identity and IAM with customers. Anything unfamiliar is complex. Long division must have seemed impossible in Roman times. It's our job to make the concepts more familiar.

Yes, we need to factor in the input along the way. But that's not the most immediate concern. We need to sell what we have.

- Mike



On 2019-01-24 07:58, Tom Jones wrote:
Mike, I believe that you make a good point, but you are IMHO, not
addressing the issue, making a secure oauth or oidc is incredibly
difficult. I think the problem is rooted in the reason for their
success. The specs are so flexible, to cover all of the many
possibilities, that the capability of creating a secure standard, or a
secure implementation, is not within the capability of most devs.
FAPI tries to fix this problem, but IMHO fails to be sufficiently
secure. Talking to some of the experts, like Justin, leads me to
believe this state of insecurity is intentional. So, do you want more
adopters or more security. You cannot have both. At least not in one
spec.

thx ..Tom (mobile)

On Wed, Jan 23, 2019, 9:28 PM Mike Schwartz via Openid-specs-ab
<openid-specs-ab at lists.openid.net<mailto:openid-specs-ab at lists.openid.net> wrote:

If Okta is blogging about this, clearly we as a community are not
doing
enough to explain the benefits and rationale of OpenID Connect...

Nobody Cares About OAuth or OpenID Connect


https://developer.okta.com/blog/2019/01/23/nobody-cares-about-oauth-or-openid-connect

-----------
Michael Schwartz
Gluu
Founder / CEO
mike at gluu.org<mailto:mike at gluu.org>
https://www.linkedin.com/in/nynymike/
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20190124/3b5367cc/attachment-0001.html>


More information about the Openid-specs-ab mailing list