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

Tom Jones thomasclinganjones at gmail.com
Thu Jan 24 16:45:32 UTC 2019


One approach that Mary Hodder is working is the creation of a web site
rating service. I personally would like to see open ID conformance as one
of the metrics of a good site.

thx ..Tom (mobile)

On Thu, Jan 24, 2019, 8:28 AM n-sakimura <n-sakimura at nri.co.jp wrote:

> 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 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
> https://www.linkedin.com/in/nynymike/
> _______________________________________________
> Openid-specs-ab mailing list
> 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
> 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/85c850b4/attachment-0001.html>


More information about the Openid-specs-ab mailing list