[HN Gopher] Dear OAuth Providers
       ___________________________________________________________________
        
       Dear OAuth Providers
        
       Author : franciscop
       Score  : 97 points
       Date   : 2024-12-11 15:42 UTC (7 hours ago)
        
 (HTM) web link (pilcrowonpaper.com)
 (TXT) w3m dump (pilcrowonpaper.com)
        
       | NewJazz wrote:
       | _It must be a JSON object with an error field._
       | 
       | What you showed is exactly that. Does the spec say the field must
       | be a string?
        
         | Nijikokun wrote:
         | https://www.rfc-editor.org/rfc/rfc6749#section-4.1.2.1
        
           | tadfisher wrote:
           | It's in Section 5, actually. That one is for the implicit-
           | grant flow, so the fields are URL-encoded and appended to the
           | redirect URI's query fragment.
        
       | politelemon wrote:
       | What's the general sentiment, is the basic auth not done by some
       | because it's considered weak security?
        
         | recursive wrote:
         | It requires the first party to the credential validation, for
         | one thing. That means you have to have a separate account for
         | every service, or expose your password for your shared account
         | to those services.
         | 
         | AFAIK. YMMV.
        
           | whartung wrote:
           | You also have to store the plaintext password Somewhere. Same
           | problem with DIGEST.
        
             | 0x457 wrote:
             | What? Why?
        
             | boopdewoop wrote:
             | Where did you get this from? You know how passwords are
             | matched right?
        
       | teeray wrote:
       | What really grinds my gears about OAuth is when there's 5
       | providers, plus an email signup, and I forgot which one I used
       | last time. Then I end up creating a new account accidentally,
       | sometimes with no way to retrieve the old one.
        
         | boopdewoop wrote:
         | Agreed, I have seen some sites check the email used and link
         | the account instead of creating a new one. I much prefer this.
        
           | lxgr wrote:
           | On one hand I like that feature - on the other hand it
           | somewhat terrifies me, since it essentially delegates email
           | verification to _any_ of their accepted OAuth providers,
           | unless they make you re-authenticate using your existing
           | credentials, or redo email verification, upon linking the
           | accounts. And not nearly all sites do.
        
           | merb wrote:
           | only works with email validation. Sadly some providers don't
           | do this (not even Microsoft azure ad in some cases...)
        
       | rguldener wrote:
       | A year ago we implemented OAuth for 100 popular APIs.
       | 
       | Our experience was exactly like OP describes:
       | https://www.nango.dev/blog/why-is-oauth-still-hard
        
       | iforgotpassword wrote:
       | > This isn't about being spec-compliant anymore. I need to know
       | the thought process behind this decision. And also please fix it.
       | 
       | Using php or something and not paying attention? Read the value
       | from database, by default php casts all colum types to string in
       | retrieval, except for a null value, or if you tell it to try to
       | match column types to php types.
        
         | __mattya wrote:
         | My guess is the JSON serializer uses strings for int64s to
         | avoid loss of precision.
        
       | xyst wrote:
       | Been considering a switch to stalw.art for my personal mail
       | server since it can also act as an IdP. Wonder how this author
       | would it.
        
         | artificialLimbs wrote:
         | If you get this command to output anything during install,
         | please let me know: "docker logs stalwart-mail"
         | 
         | Have reached out on multiple channels and only crickets.
        
       | Onavo wrote:
       | Discord also doesn't work with Firebase OIDC.
        
       | jamamp wrote:
       | I'd like to add that so many providers do not support either
       | `prompt=select_account` or just natively ask the user which
       | account to login to, mainly for OIDC. Working with IAM systems at
       | work and using different test accounts, it's frustrating when you
       | can't easily log out of the destination IdP for, say, SSO.
        
       | EmilienCosson wrote:
       | Thank you.
        
       | magicalhippo wrote:
       | For open standards like this, it would really help if there was
       | an official, readily available test suite anyone could run.
       | 
       | Sure there's the spec, but it's a lot to keep track of for the
       | intern that inevitably ends up implementing such things.
       | 
       | Having a test suite you to verify you didn't mess up would be
       | very useful.
        
         | d4nt wrote:
         | Like this: https://openid.net/certification/about-conformance-
         | suite/
        
           | Terr_ wrote:
           | I only dabbled with OpenID as an end-user, but I really
           | _really_ liked the fact that I could tie my identity to a
           | domain I owned, and then temporarily delegate the credential-
           | mechanics to another entity.
           | 
           | In this way, the identity was durable and portable, at least
           | as long as one maintains control over the URL.
        
       | ryanmarsh wrote:
       | You had me until "Please support HTTP basic auth for client
       | authentication".
       | 
       | OAuth 2.1 draft spec emphasizes that basic auth is no longer
       | preferred. I read that to mean: MAY, or perhaps even SHOULD NOT.
        
       | jamamp wrote:
       | Dear Okta, please include your OIDC profile claims in your ID
       | tokens.
       | 
       | Actually no, that's on the spec for not enforcing they're in the
       | ID token, and only must be available in the userinfo endpoint.
        
       | SeenNotHeard wrote:
       | Some of these problems (esp. Facebook's) look like someone used
       | an existing service framework to code OAuth2, and either didn't
       | or couldn't adjust the framework to conform to spec.
       | 
       | Some of the other problems look like a common problem with
       | scripting--the ease of treating an int like a string, and vice-
       | versa.
       | 
       | "This isn't about being spec-compliant anymore. I need to know
       | the thought process behind this decision."
       | 
       | May not be a thought process, just a rush to get the service into
       | production, and a lack of attention to detail. Lots of coders
       | treat error-handling as a hassle or optional, hence the 80-20
       | rule.
        
       | lxgr wrote:
       | OAuth is such a bad standard, if you even want to call a loosely
       | cross-referenced bundle of RFCs that, only thinly obscuring the
       | real message: "Leave this to the professionals and just use our
       | custom libraries, or maybe an authentication SaaS".
        
         | siva7 wrote:
         | Which are buggy as hell
        
       ___________________________________________________________________
       (page generated 2024-12-11 23:01 UTC)