
Nobody Cares About OAuth or OpenID Connect - rdegges
https://developer.okta.com/blog/2019/01/23/nobody-cares-about-oauth-or-openid-connect
======
simonw
I'm trying to build a simple Python app that authenticates against corporate
Okta right now.

It's incredibly, painfully difficult. If you search for "Python Okta" you get
this:
[https://developer.okta.com/code/python/](https://developer.okta.com/code/python/)

> At this time we do not support official API client libraries (SDKs) for
> Python. You may fork our legacy Python SDK or join the conversation on this
> thread and let us know how you’d like to use Okta from Python applications.

I have integrated both OpenID and OAuth by hand many, many times. If Okta
offered a page of documentation like this one my project would already be
finished: [https://developer.github.com/apps/building-oauth-
apps/author...](https://developer.github.com/apps/building-oauth-
apps/authorizing-oauth-apps/)

From the linked article:

> This is one of the reasons why, here at Okta, even though our entire
> platform is built on top of OAuth and OIDC, we spend tons of time and effort
> trying to build abstractions (in the form of client libraries) to hide those
> complexities and make securing your web applications simpler.

But this is the cause of my problem! The abstractions they are offering don't
work for my use-case. The fact that they have hidden the complexity from me is
actively preventing me from completing my goal.

I'm not arguing against abstractions here - what I need is BOTH. I need
abstractions that can help me get my job done, combined with well documented
non-hidden complexity for me to fall back on if the abstractions don't yet
handle my use-case.

~~~
rdegges
We don't have any official Okta Python library support at the moment :(

We don't have any full-time Pythonistas on staff right now, so deprecated our
old stuff. We're hoping to hire and expand that role out to build proper SDKs
+ support in the future.

Right now, the best option is to use generic OIDC/OAuth compliant libraries
(since Okta is a generic OAuth/OIDC provider). Sorry :(

~~~
merlincorey
The company I work for recently became an Okta Partner... and I'm a Software
Engineer that primarily works in Python.

I am expecting this quarter to start building out a platform that will use
Okta for authentication and authorization.

Do you think Okta would be willing to pay for some engineering hours if we
were to take on the mantle of producing a modern Python SDK? If so, I'll be
happy to start running that up the line here.

Failing that, are there any resources you recommend for going forward with
Python and Okta, in addition to using generic OAuth libraries?

~~~
rdegges
That is awesome! I'm going to forward this comment to our DevEx team and see
if that's something we could do. Sounds great to me =D

~~~
merlincorey
Excellent -- I sent you an email to the address in your profile from my work
email in case anything comes of it.

------
aclimatt
The article provides a very light history and technically shallow description
of OAuth and OIDC so it can advertise Okta. Essentially, "these two protocols
are complicated, and you probably don't care, so you should buy Okta."

Except this is Hacker News, where caring is fundamental. I'll pass on the Okta
advertisement.

~~~
rdegges
I'm legitimately not trying to advertise for Okta here at all.

This topic is near and dear to my heart because I've been working in this
industry for many years now, and it is frustrating that there is a huge focus
on building more OAuth/OIDC tools and encouraging developers to get directly
involved in working with things like JWTs directly.

There are so many ways to mess things up at foundational levels today, I just
really want to see better tooling created in the open source communities (and
in paid products) to abstract things like OAuth/OIDC so that developers don't
_need_ to constantly be fiddling around with these lower level protocols where
the risk for messing up is extremely high.

~~~
jessaustin
Advertisements with their hearts in the right place are still advertisements.
If your tool were open source (it may be? not clear from TFA...) no one would
complain. Since it's commercial and TFA takes such an anti-hacker stance, the
complaint above is not surprising. It's not difficult to imagine that TFA
might be very effective in speaking to some of your customers. With the
customers who hang out here, a different essay with a different emphasis (e.g.
"this is how everyone gets OAuth wrong and here's how we do it right") might
be more effective.

------
zxcvbn4038
The redeeming feature about OAUTH, like pretty much anything security related,
is that if you don’t give people a standard to follow then you are probably
going to end up with something that is insecure and poorly implemented.

A lot of people just don’t have the background to do good security work, and
when you try to explain why a short lived credential is good, or why we can’t
have a plain text password embedded in the git repo, their eyes glaze over and
you lose them. So it’s much easier to just dictate it will be a tls connection
and you’ll use OAUTH, and then they go download a library and everything is
good.

Where I ran into problems is with using OAUTH for federated user logins. I did
a proof of concept with Facebook, then after a couple hours they decided I was
a robot and that was that - account closed, no recourse. Luckily that happened
before I had a large user base using it - I don’t know what you do if Facebook
decides your a robot and suddenly 50,000 people can’t authenticate to your
site, guess you learn something. A week later most of the other sites decided
I was a robot and terminated my accounts. Google is the only site that didn’t.
(Which is good because I have a decade of e-mail and photos I’d hate to lose)

~~~
unclebucknasty
> _don’t know what you do if Facebook decides your a robot and suddenly 50,000
> people can’t authenticate to your site_

This is exactly why I am paranoid about depending _entirely_ on social sign
up/in. So if the API provides it, I believe it's a good idea to capture the
email address associated with the social account and either generate a hard
password for later reset if necessary or request the user set one up. The
latter obviously reduces a little convenience of the social sign up, but does
hint to the user that they can sign-in otherwise and gives them control.

Authentication is just too important to completely outsource without recourse.

~~~
brokenwren
_> Authentication is just too important to completely outsource without
recourse_

I agree 100%. You need to own your users and all of their data. Along those
same lines, I wouldn't want my user data going into a multi-tenant, cloud-
hosted solution like Okta. I'd much prefer to store everything on my own
servers or use an on-premise solution like FusionAuth or KeyCloak.

~~~
unclebucknasty
> _...use an on-premise solution like FusionAuth or..._

[https://news.ycombinator.com/user?id=brokenwren](https://news.ycombinator.com/user?id=brokenwren)

I see what you did there. :)

Good luck.

~~~
brokenwren
Haha. I try to be upfront that I work for FusionAuth. I mentioned it in my
other comments in the thread but forgot to mention it here. Thanks for keeping
me honest. ;)

------
wedowhatwedo
The author of this article cannot be trusted. He regularly writes articles
that compare non-best practices of JWT to best practices of other technologies
to make JWT look bad. Because of him, I would not trust Okta at all. Take any
article by Okta with a grain of salt.

~~~
CuriousSkeptic
What practices would that be? Both good and bad is interesting to me.

I recently decided against using jwt bearer tokens due to the concerns
expressed in both rfcs and owasp of being to risky when compared to session
cookies.

But really I’m wondering if the risk of screwing up csrf protection isn’t more
of a concern than token leaks.

------
ChartsNGraffs
If you need to implement your own OIDC/OAuth I highly recommend Identity
Server 4[1]. I've used it in production and it was fairly painless to get up
going. It's .NET based & battle-tested. It has lots of samples on GitHub to
show you how to get going for the various flows (which they even walk you
through in their docs) and has a quickstart UI so you've got something you can
brand quickly to give users a contiguous login experience. However, if you can
manage not to host your own (don't want to mess with it), I recommend either
Auth0[2] or the one of the AWS/Azure solutions mentioned elsewhere.

[1][https://github.com/IdentityServer/IdentityServer4](https://github.com/IdentityServer/IdentityServer4)
[2][https://auth0.com/](https://auth0.com/)

------
wvh
I implemented a minimal OpenID Connect server internally a few years back when
it was difficult to find something for our specific use case in Go. I think
that while the general idea is good, the spec is a mess: it's too flexible in
all the wrong ways, so every large player implements it slightly differently,
leaving you with no clear path to go yourself; and actually making the
protocol (... concept?) less secure than it could be.

I kept thinking that for our use case, a simpler aead token or perhaps
something like Maracoons (if there would be more battle-tested libraries for
it...) would suffice. In the end I implemented a partial solution with one
flow and one JWT signing algorithm so the other services could rely on
existing client libraries for their respective programming languages.

Of course none of it ended up being used, as SAML (there's another can of
worms...) support became a requirement and some large framework was brought in
for that corporate software feel-good factor...

I agree with the sentiment that it would be nice if there would be new
development in this area, even (or especially) if none of the big players are
involved, but non-trivial crypto protocols and frameworks seem to need a lot
of momentum to break out of their local ecosystems. It's not easy to design
something that fits different use cases yet doesn't break at the joints.

~~~
javier2
> I think that while the general idea is good, the spec is a mess: it's too
> flexible in all the wrong ways, so every large player implements it slightly
> differently, leaving you with no clear path to go yourself

This was my experience doing _anything_ at all with OAuth. Now I am seeing the
same with OpenID Connect, though not as severe. The spec was narrowed a bit,
but it is still way too broad.

~~~
dwaite
I recommend looking at the basic client profile of OIDC to start. It is a good
cut through all the options.

Also you may want to look at the OIDC conformance testing tools for testing if
you are building your own library or server. Certification costs money, but
the conformance testing tools I believe are all open source.

------
tofflos
I agree that the learning curve is too steep with OAuth and OpenID and that
supporting multiple scenarios could be part of the problem.

One specific problem I've faced is that it's very complicated to configure a
development environment for unit and integration testing. I think there is
huge demand for something that works well for Docker Compose and unit testing
frameworks while still being a production grade solution.

I haven't evaluated everything out there but so far the best solution I've
found is Keycloak. Unfortunately it takes 20 seconds to start on my computer
and up until very recently I had to go through the configuration procedure
each time you launched tests. I was fortunate enough to get a PR
([https://github.com/jboss-
dockerfiles/keycloak/pull/152](https://github.com/jboss-
dockerfiles/keycloak/pull/152)) accepted which allowed me to load a working
configuration file directly into the unaltered Docker container with some
users and roles for testing purposes.

So if you have something that starts quickly, is easy to combine with Docker
Compose and with unit testing frameworks, and could be used in a production
scenario... Let me know. ;-)

Oh, and it also needs to be on-premise.

~~~
mraible23
I agree that Keycloak + Docker Compose is a great combination for development
and testing. We use this setup in JHipster
([https://www.jhipster.tech](https://www.jhipster.tech)) when you choose OIDC
for authentication. It auto imports users, roles, and OIDC apps so everything
works right away.

~~~
brokenwren
Matt, you guys should switch JHipster to FusionAuth! Less IBM-ness you know.
;)

------
SomeHacker44
I recently built an app that outsourced the entirety of the account creation,
email validation, MFA and authorization to AWS Cognito and AWS ELB. All I have
to do is verify a signed JWT passed in by a header by the ALB (and configure
all that stuff and automate it into CloudFormation).

Never building this infrastructure again. What a huge time saver.

My company used Okta. We ended up cancelling it as it did not seem to offer
any value whatsoever and was crazy expensive for our 300-odd users.

~~~
scopendo
Is that architecture helpful for a saas app that needs to support users from
corporate customers using single sign-on via an OIDC or SAML provider like
Azure AD or ADFS?

I looked into using Okta or Auth0 for this sort of setup, but both were
prohibitively expensive for a saas app.

~~~
brokenwren
FusionAuth is free. Less pain, more awesome! ;)

And it integrates with AAD and ADFS.

------
perlgeek
Maybe off-topic a bit, because it only handled authentication, but I really
miss Mozilla Persona.

You just included some javascript in your frontend, maybe a 5-line function in
the backend, and people could authenticate to your web app.

No need to store a password and correctly crypt the hash, provide a password
change function, provide a password reset function (what a PITA to get
correct).

Why hasn't anybody created something comparable yet?

------
spricket
This is a sales piece for Okta. And I disagree with them.

OpenId Connect and OAuth work great and are reasonably designed. The
documentation is dense but you'll do fine if you read some of the popular
blogs about it summarizing the different flavors.

Their comparison to "rolling your own crypto" is jarring. Rolling != using.
You're likely a moron if you write your own crypto library and that applies to
not using pre-made OAuth/OIDC libraries as well.

------
colinfinck
The complexity of OpenID Connect or even just SAML is exactly why I developed
RosLogin for the ReactOS infrastructure:
[https://github.com/reactos/web/tree/master/www/www.reactos.o...](https://github.com/reactos/web/tree/master/www/www.reactos.org/roslogin)

Our web services are all running under the same base domain reactos.org and we
wanted a Single Sign-On system for all of them. I was surprised to find out
that doing this simple seems to be an unresolved problem: CAS, OpenID Connect,
and SAML all want you to set up heavyweight authentication servers and a
certificate infrastructure for identifying each participating web service. A
lot of protocol messages need to travel for a simple action like a user login
when a site-wide session cookie could just do the same job. Sure, those
systems support advanced features like access control and delegated
authentication, but this is all not required if you just want to link a few
web services under your own control, say a MediaWiki and phpBB forums.

RosLogin simply sets a site-wide session cookie on each user login. Each web
service then just calls RosLogin::isLoggedIn() to check its validity and
retrieve the user name. No certificates, no protocol messages, and no
heavyweight server software is involved. Together with centralized Login,
Registration, and Self-Service pages, RosLogin currently needs no more than
1600 lines of PHP code - perfectly auditable from a security standpoint!

The ReactOS infrastructure is mostly built around PHP web services, so PHP
bindings and plugins for Drupal, MediaWiki, and phpBB are currently the only
ones available for RosLogin. However, our few non-PHP services can still plug
into the same user database by connecting to RosLogin's underlying OpenLDAP
directory.

------
woranl
OAuth 1.0a handles both authorization and authentication. I still think it’s
unfortunate that Big companies are pushing for OAuth 2.0 and trying to
blindsided developers as if OAuth 2.0 is an upgrade to OAuth 1.0a. It is not!
OAuth 1.0a provides authenticity, integrity, and non-repudiation. Something
that OAuth 2.0 cannot match.

~~~
rdegges
I agree! I really liked OAuth 1.0, especially from a security POV. But, the
working group has moved on, and OAuth 2 is the standard now :x

~~~
woranl
Not everyone is using OAuth 2. Mastercard makes a security decision to stay
with OAuth 1.0a.
[https://news.ycombinator.com/item?id=17482178](https://news.ycombinator.com/item?id=17482178)

~~~
brlewis
Also twitter whenever the app is supposed to act on behalf of a user. (OAuth 2
is simpler, and is available for accessing public data not on behalf of a
user.)

[https://developer.twitter.com/en/docs/basics/authentication/...](https://developer.twitter.com/en/docs/basics/authentication/overview/oauth.html)

~~~
dwaite
Twitter is very reluctant to find out how much removing OAuth 1.0a (and their
previous incarnations like XAuth) will break in their legacy infrastructure
and for existing trusted clients. A migration path would mean adding OAuth 2
in addition to all the previous mechanisms, and then likely acting over a long
migration timeline.

------
rossdavidh
So, I know I'm naive and all, but it seems odd to me that this isn't baked
into normal web frameworks. It is entirely ordinary for a website to want to
allow a user to login using Google/FB/Yahoo/whatever other id's, so that they
don't have to make a new id (and remember a new password) just for your
website. Probably half of the websites made with frameworks want this.

Oddly, if I want to do it, I rarely find this "baked in". Many other features
which are less common, are, or else have middleware that makes it pretty much
just "add this line to your config file".

I have had to mess with Oauth two or three times in ten years, so needless to
say I am hapless at it. If I did it less often, or more often, it would be
fine, but it's not. Does anyone know why this isn't rolled into frameworks
like Django, as a boolean that you set to TRUE?

~~~
AdeptusAquinas
Its baked into ASPNET Core, and its still a pain in the ass.

Even though the middleware handles JWT validation, cookie storage, redirects
etc (which are a big part of it) there are still a tonne of little details to
OAuth that clients need to know enough to specify:

\- what grant flow are you using (code, hybrid, implicit, resource owner etc..
all are valid for different and overlapping scenarios, based on how secure you
want to be and how much hassle you want your users to experience)

\- client id and secret management, and registering this with your server

\- refresh tokens: i.e. how do I prevent my user needing to log in every 15
minutes without making my jwt last an insecure amount of time.

etc. etc. etc. I've built OAuth/OIDC into dozens of apps, and have deployed my
own identity providers (not rolled my own, thank the gods, just used a
framework for the server side) and its still the bane of my development
existence.

~~~
zxcvbn4038
That is another good point - generally you want to force a user to
reauthenticate whenever they enter an elevated security context (account
management, personal information, etc). With the OAUTH flows there doesn’t
appear to be s way to do this. If I tried to send them through the login
process again, they would just end up back at my callback address because
their token was still valid.

~~~
dwaite
Two ways to interpret your problem:

1\. You want to perform a stronger form of authentication for users who are
interacting with certain parts of your application

In this case, you can proceed in two ways. One would be to use the OpenID
Connect authentication context parameter and request the stronger form of auth
directly. I personally dislike this approach because it bleeds business logic
into all your clients, although it is popular in some government use cases
(where authentication levels are part of the API contract).

You can also have the applications represent the elevated security context as
scopes (e.g. a moderation or admin scope). The business logic within the AS
can interpret requests for these scopes as requiring stronger authentication

2\. You want to reauthenticate the user when they go to an elevated security
context.

The AS should be responsible for your authentication policy, and deployments
tend to go simpler if you don't split this responsibility with the
application.

The traditional way to do this would be similar to the scope rule above:
scopes representing access to elevated contexts, and the AS recognizing it
needs to enforce stricter authentication rules for this to work. For instance,
you could have a rule that the user needs to reauthenticate every half hour,
and make access tokens which have elevated privilege scopes have a limited
lifetime to force retrieving a new token.

A more modern way to do this might involve stepping back and looking
holistically at why you are reauthenticating the user. This might be because
you are worried that someone may have walked up to an unlocked machine and
proceeded to try to access administrative features.

For this, you might instead look at using EMM and machine policy to reduce
that risk rather than impacting UX - such as reducing the time of the screen
lock and eliminating the ability to use hot corners to keep the screen awake
for users with administrative access. Your AS can then detect and rely on EMM
compliance as a factor.

------
sebringj
The reason it (OAuth) was built was for user convenience one-click signing in
for the most part and frankly that is more important than most considerations
or tradeoffs if it's accomplishing the job. I do feel like this is always a
bear to put in apps and I've even gone to the lengths of making a highly
reusable microservice to handle this for my apps because it is just annoying
in general to keep setting up. I don't like igcognito or firebase as they are
too limiting on providers. I just took the approach of using an already rich
ecosystem of Node.js and Passport compatible plugins for providers and having
config lookup based on both signed requests coming in and where they
originate. Was definitely worth the time doing this.

------
rishav
Isn't this like a bicycle company saying no-one cares about walking anymore ?

------
mevile
We've started using AWS Cognito which provides social logins and oauth and
even mobile client and web sdks for integrating. Writing yet another
authentication system was just too much and it's great how there's services
like okta and aws that are stepping up and letting people just use those and
at least in the case of Cognito, at minimal cost.

~~~
brokenwren
I've heard that Cognito is very limited in terms of features and can be a
headache to get working properly.

I haven't used Cognito, but I work for FusionAuth
([https://fusionauth.io](https://fusionauth.io)) and we have a number of
developers that have switched from Cognito to FusionAuth because we cover more
of their use cases outside of plain authentication.

Not sure if you have had similar experience with Cognito being limited.

~~~
mevile
Well Cognito is a different product from what fusionauth is. As far as I know,
Cognito is not going to be what you want to use for SSO for example. It's more
for consumer facing services. As for hard to set up, that hasn't been my
experience. If you're familiar with aws already it's trivial and interacts
with other aws services. Like you can let users directly upload to s3,
authenticate automatically via api gateway. I got it working pretty quickly.
The mobile app support is great too. Cognito is also much cheaper than okta.
You don't pay anything for the first 50,000 monthly active users.

------
altmind
Original OpenID implementation was so simple and the scope of it was so small,
i wonder where we got all this complexity

~~~
nailer
OpenID (not connect) had a weird OpenID URL users had to care about. Mine was
something something google something u8. Nobody cared. Sites like HN removed
OpenID logins. OpenID died.

OpenID Connect just standardised the existing practice of being authorised to
use an identity provider as a type of authentication.

Edit: actually something something o8:

[https://www.google.com/accounts/o8/id](https://www.google.com/accounts/o8/id)

Again, this was required for USERS, not developers.

This is someone asking how to log in:
[https://webapps.stackexchange.com/questions/18899/how-do-
i-f...](https://webapps.stackexchange.com/questions/18899/how-do-i-figure-out-
my-google-openid-url)

~~~
Nullabillity
This is an implementation issue, not a spec issue. Pages can delegate to
another identity provider (primarily used for vanity URLs, for example I could
say that [https://nullable.se/](https://nullable.se/) should map to my Google
OpenID, for example), and the identity provider can claim a different URL than
you asked for (for example, Steam always uses
[https://steamcommunity.com/openid](https://steamcommunity.com/openid) as the
provider, but will claim a different URL for each user).

Combine these, and Google would have been perfectly capable of making everyone
just type google.com. That they didnt' says more about Google than OpenID.

Besides, people were perfectly capable of showing the same pickers back then
as you are forced to use with the current OIDC/OAuth2 abomination.

~~~
nailer
> That they didn't says more about Google than OpenID.

HN did the same thing. In fact pretty much every OpenID site implemented this
weird expectation. Part of helping a standard get adopted is making sure it's
implemented correctly.

------
tebruno99
I kinda feel like this was on the right track but then it turned into, let me
sell you something.

------
colemickens
Here's my problem with OIDC and I don't know where to bring this up to find
out if my hopes are widely off or I've missed something big and it already
exists...

There's nothing specified anywhere that allows an application to interrogate
an RP about the available scopes. I just don't see how fine-grained resource
access can be done with OIDC without requiring the user to grant much coarser
access first. I found a draft spec once but it was abandoned and the author
didn't reply to an email I sent...

~~~
arkh
And a problem for the Resource Server: no common way to check the validity of
a token. You may be lucky and get a JWT but even then there's no specified URL
to get the keys to check it. Usually you get an opaque token and hope the
client gives you a way to know where it comes from so you can do some specific
server to server call.

So you can't implement an independant RS which does not care about clients and
how they authenticate their users.

~~~
hirsin
Look at the JWT, take the issuer claim, take the .well-known config off that
url, and you have keys. Match that against the known permanent issuer you
expected, and verify the signature of the JWT against the keys. If you're
accepting things that aren't JWTs then you're not doing oauth.

~~~
arkh
> If you're accepting things that aren't JWTs then you're not doing oauth.

As a resource server:
[https://tools.ietf.org/html/rfc6749#page-10](https://tools.ietf.org/html/rfc6749#page-10)

Access tokens don't have to be JWT. And some OpenID authentication server give
opaque tokens: your resource server has to know how to call it to check the
token and get some user infos if available.

~~~
hirsin
Yes, I misread and typo'd.

------
leowoo91
Years ago, I did care about adding FB login for a while, until my app has been
removed from approval because of some strict guidelines. I'm pretty sure it
required effort to resolve. From these days, I didn't even consider adding any
oauth unless good presence for the project is achieved.

------
MrStonedOne
This article kinda glossed over what the fuck openID Connection is actually
for.

Like in a big way that I have no idea what the fuck OpenID is, what
authorization and authentication are in this context, and why oauth doesn't
handle both.

~~~
dexwiz
Authorization = Can I do this?

Authentication = Am I this person?

Technically, OAuth only cares about Authorization. It provides an opaque token
to the client that authorizes future requests. It doesn't tell the client
anything about who the token is for.

Turns out most clients need to know who is logged in (such as loading basic
profile information, email address, avatar, etc). In practice this is usually
done through some sort of /user endpoint that accepts an OAuth token. This
/user endpoint implementation is service specific.

OpenID Connect tries to fill that space by providing a standardized way to
perform authentication and identity information.

~~~
dwaite
More than that, the bearer model of OAuth doesn't guarantee the token
represents a particular user or even a particular client.

Any assertion that you are dealing with a particular person needs to be
targeted at you. There were security vulnerabilities with some early OAuth
deployments that used OAuth for authentication which didn't understand this -
and that allow one service that had a relationship with a user to act as that
user against all other services which trusted that AS.

For Facebook, they solve this by having the token stamp information about
which client it was issued to, which the client is required to verify. For
OpenID Connect, they decided to preserve the ability of OAuth access tokens to
be opaque to the client, and create a new token called an id_token.

------
qwerty456127
> Back in pre-2007, there was no way for developers to build apps that needed
> to securely access user data in another service.

I understand there are cases and people when this is needed but as for me I
bloody never want anybody to access my "user data in another service" and
that's why I strongly prefer plain old email sign-up: in many cases if you
sign-up with your google account the service will also request your contacts
list, your personal details and everything and I never want to share these.

Nevertheless the single sign-in feature OAuth/OpenID provide seems very
convenient (unless implemented improperly when the service would take your
OpenID and still ask you to set a password, a login name and/or e-mail
address) so I still use it for some services.

~~~
wil421
Just think about companies like Mint who scrape your banking and financial
information using your creds. Not sure if Mint has changed this or not (or if
the banks opened an API) but at one point it was the case.

In the enterprise space these solutions help a lot. Especially with the rise
of enterprise cloud software solutions like Salesforce, Workday, and
ServiceNow.

~~~
rdegges
They still do that for 99% of the banks, since most banks don't support
OAuth/OIDC yet :(

Chase recently switched over to OIDC which was pretty neat, but for most
banks, it is an absolute nightmare.

~~~
dwaite
There are several initiatives (such as Open Banking) which are mandating
certain levels of access.

------
stillbourne
I care...

------
graphememes
tl;dr nobody cares how the sausage is made. they just want the sausage. they
are hungry.

~~~
chias
Unless I'm misinterpreting, this apparently includes the people whose job it
is to make the sausages (i.e. Okta).

~~~
graphememes
After spending enough time making sausages, I too, would not want to know

