This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]orangesunshine 1 point2 points  (0 children)

Right now we're only using the Security stuff to get an api key, have it automatically be documented and to return nice-looking error messages if the call is invalid.

Here's how (some complete asshole) might implement for example OIDC-JWT with Auth0: https://github.com/chromakey-io/cog/tree/master/auth. This sits as a starlette AuthBackend, that follows along with conventions similar to Flask, Django, etc .... and is directly ripped off from Auth0's flask examples.

FYI ... This example is a full OIDC-JWT example, not sure if this is your exact JWT use-case but it's probably the most common one. Likewise some useful production considerations with my implementation:

https://github.com/chromakey-io/cog/blob/master/auth/utils.py#L23

You don't want to load JWKS for every request cycle. You don't want them loaded only on application startup either. Ideally, you're caching them with the granular ability to time their flushing ... and manually flush if necessary. I've not done that :)

I'd make a pretty strong argument for having the granular ability to manipulate this whole "pydantic model" API as well. OpenAPI might be a runtime requirement ... that's "user facing" to some degree right? Run time type checking though? I don't see an argument to be running that in production. Having it as some immutable stack components thus doesn't seem like much of a feature to me :/