Why is OAuth still hard in 2023?
251–260 of 290 posts
Re: Why is OAuth still hard in 2023?
#252Earlier quoted context omitted.
when it comes to this kind of things there's really no way around it: you're supposed to read the RFCs: - https://www.rfc-editor.org/rfc/rfc6749.html : The OAuth 2.0 Authorization Framework - https://www.rfc-editor.org/rfc/rfc6750.html : The OAuth 2.0 Authorization Framework: Bearer Token Usage
As someone who is hired to sling out features as rapidly as possible, that’s not going to happen. I mean, you might say “but you should” or “it would actually help” or “in an ideal world…” but it is still, realistically, not going to happen.
> As someone who is hired to sling out features as rapidly as possible, that’s not going to happen.
you do you, i guess.
but that's where the source of truth about how oauth 2.0 works is.
the "why" you're looking for it's in there.
Re: Why is OAuth still hard in 2023?
#253Earlier quoted context omitted.
when it comes to this kind of things there's really no way around it: you're supposed to read the RFCs: - https://www.rfc-editor.org/rfc/rfc6749.html : The OAuth 2.0 Authorization Framework - https://www.rfc-editor.org/rfc/rfc6750.html : The OAuth 2.0 Authorization Framework: Bearer Token Usage
That doesn't explain what the library is trying to do and how it implements it though.
if the library is implementing oauth 2.0, that explains what the library is trying to do.
how it's implemented... well that's an implementation detail, that most often one couldn't understand without the domain knowledge (unless it's something "trivial" like an off-by-one in some string comparison or something like that).
Re: Why is OAuth still hard in 2023?
#254Earlier quoted context omitted.
That's something that isn't OAuth2 or your end point is accepting something insane. Are you talking about the PKCE variant of authorization code flow which is what replaces implicit flows in native apps and SPAs? Because those use code_challenge and code_verifier fields, not the state field. If you're doing all that in the state field with signed nonces you really should move to PKCE.
Using [0] as a reference, I'm talking about Step 3. This is, in my experience, the "normal" way that people are setting up OAuth between 2 services, with a user going through the flow. [1] includes info on this (see "flawed CSRF protection") [0]: https://www.digitalocean.com/community/tutorials/an-introduc... [1] https://portswigger.net/web-security/oauth
Aha! That makes sense! Yes that can be a problem. We exclusively use a single (our own) IdP so it's less important for us. But good to know as some future feature work will actually make this important.
Thanks!
Re: Why is OAuth still hard in 2023?
#255Earlier quoted context omitted.
That doesn't explain what the library is trying to do and how it implements it though.
if the library is implementing oauth 2.0, that explains what the library is trying to do. how it's implemented... well that's an implementation detail, that most often one couldn't understand without the domain knowledge (unless it's something "trivial" like an off-by-one in some string comparison or something like that).
Yes, that "domain knowledge" is kinda important when you're trying to debug a blob of code that results in random permission errors after OAuth request.
The "implementation details" are what we're tasked with implementing ;)
Re: Why is OAuth still hard in 2023?
#256Earlier quoted context omitted.
Thank you! Not sure, just part of the orange site mystery~ Your `onlogin` callback will only ever be invoked by the SDK on successful login. So the data coming thru there is always the result of the OAuth flow itself. For MPAs, you can create your own document cookie and/or modify local/sessionStorage, and then every new page load will pull/load from those storage systems. SPAs can & should do the same – they just ha…
Ah great, thanks! It would be great to see a larger example on your site to see how this all ties together. For example, I don't really understand what's stopping anyone from opening dev console and just calling my 'onlogin' callback and passing it fake data to impersonate another user. It seems to me that somewhere I'd still need to verify the user data with the provider. I fully realize that that's probably due to…
For sure! There are some larger examples coming so that people can see it plugged into a more real-world application.
RE: onlogin, that method accepts a callback handler that is added to an internal/private array of callbacks to run once the `popup` or `redirect` sequence has finalized. It's the only externally-facing "doorway" into the OAuth flow. Everything else is inciting action (`popup()` and `redirect()`) or a read-out of the last-known payload (`last()`). It's actually very similar to a state manager I wrote a while back[1]. Callbacks are added via `$.on()` which assembles an internal `tree` map to be `dispatch`d once a change happens.
You've probably already seen the API docs for the btn.social SDK, but linking just in case[2]
[1]: https://github.com/lukeed/vegemite/blob/master/src/index.js
Re: Why is OAuth still hard in 2023?
#257It'd be interesting to hear about people who have had a good time implementing OAuth, as my experience is similar to that in the article. I've played with adding it to a few side projects and the process usually goes: 1. Read loads of docs, end up pretty confused 2. Find a library that seems to do what I want 3. Install this huge library full of opaque code doing...things 4. Have an impossible time troubleshooting is…
3b. realize that library is deprecated or hasn't been updated in many years and is either totally broken, or incompatible with something else you're using.
3c. Write your own "library" which encompasses the the 50 lines of code.
Adding the oauth calls into your app that already has a web server, job processing, and a db is way easier than integrating what ever weird stuff some random library does.
Re: Why is OAuth still hard in 2023?
#258Earlier quoted context omitted.
> it is true that majority of people I interacted with are having troubles understanding these protocols. However, what I can attest to is that they're also extremely underwhelming as people working in IT, with bad work habits and misplaced focus. It's impossible to explain or clear up the protocol to such audience because they lack much more when it comes to knowledge and discipline. In my experience, IT generalists…
Can you share any of your training materials?
Unfortunately I cannot as they all belong to that employer and there are some privacy implications to linking the content as-is, but I’ve been thinking about reframing the ideas behind the content as a more general intro to OAuth and publishing a series of vendor-agnostic blog posts and/or videos.
Re: Why is OAuth still hard in 2023?
#259Because the underlying problem is hard. SAML is difficult too. Identify federation, across the public Internet, between disparate entities is a fundamentally difficult problem with no simple answers.
Re: Why is OAuth still hard in 2023?
#260Earlier quoted context omitted.
> In my experience with OAuth, one of the principle issues is that it's less a protocol and more a skeleton of a protocol OAuth supports lots of different scenarios. Many people when they say “OAuth” they are only thinking of one or two of those scenarios, and ignoring all the others which aren’t relevant to them personally-but may be relevant to someone else I worked on a system where we had a micro-service which ha…
> > In my experience with OAuth, one of the principle issues is that it's less a protocol and more a skeleton of a protocol > OAuth supports lots of different scenarios. But it's literally only the skeleton of a protocol ("framework" of a protocol, as the actual spec puts it). That important "Then later on you can take the token and say 'Hey google, somebody gave me this token, who is it?'" part is totally unspecifie…
Yikes. As someone who is going to need to integrate OAuth using JWT into a Rails app to access an API in the nearish future... I now dread it.