Using JWT with independently distributed keys for verifying authorization
info has worked best for overall performance in my experience so far (in
microservices generally; not tested with OW). Using that pattern minimizes
auth server contact thanks to cryptographic verification of the JWT. Also
It might not be directly related to the agenda but one small thing to note
is the response time of the auth/authz server should be considered as well.
When I implemented LDAP integration, the LDAP server was too slow.
It took about 100ms ~ 1s to authenticate users.
Even though I took advantage of
Rodric,
IBM Cloud Functions hasn’t implemented OAuth, but JWT based bearer token based
authentication based on the IBM Cloud IAM system.
The first problem we encountered was that our bearer token did not provide a
namespace related context
(which is only configured in the IAM system). The
As a budding security engineer, I’ll suggest to emphasize role based
security authorization rather than a permission model. It’s easier to
maintain over time, and it’ll map well to OAuth scopes as well as in JWT
metadata, plus it’ll likely still adapt well to whatever new security
standards are
Rodric I think having additional authentication methods no one will object, but
the devil are in the details :-)
Also when you say things like “replace” with no more context some folks that
are using the software in production, quickly jump into the conclusion on “Now
I have thousands of end
I'm curious if anyone has thought about or implemented an oauth based
authentication mechanism in the controller. I've thought about replacing
the subject authentication with oauth and think it would not be a lot of
work to do although it does have some wider implications.
-r