Refactor and new features

[samedii]

• Select grant flows for docs
• Granular optional auth for endpoints with auth.required and auth.optional
• Granular scope verification with Security instead of Depends
• Slightly more transparent argument names
• Follow openid connect specification for verification more closely
• Github action for publishing (requires a pypi token in github secrets)

[HarryMWinters]

Hey @samedii.

Your code is good. It's better than what I wrote in most ways. But you have a 600+ line PR in repo whose source code was a third that size. And your changes are breaking the modules API.

So I have to ask, why use this package at all? Why not just publish your own?

EDIT: It probably is worth getting into this library so there are not two options floating around. We'll just have to cut a 1.0.0 release for all the breaking changes. The smaller we can keep the PRs the easier it's going to be for me to be able to make time to review them.

[samedii]

Yes if you don't want to merge this then I will have to publish another. There are already a lot of alternative packages on pypi (that don't have working docs)

Breaking this up into many small PRs will be extremely time consuming. I'll probably temporarily publish and then you can have a look at the total. If you want to merge then we can do cleanup/rewrites however you prefer

[HarryMWinters]

Well, let me know when the branch is ready for review and I'll go over it when I can. I'm not at to ReadTheDocs btw if you've got a preference for something else.

[samedii]

I'll probably make minor cleanups and doc changes but it's largely done now.

Do you have a use case for having another audience than client id?

This is from the specs:

REQUIRED. Audience(s) that this ID Token is intended for. It MUST contain the OAuth 2.0 client_id of the Relying Party as an audience value. It MAY also contain identifiers for other audiences. In the general case, the aud value is an array of case sensitive strings. In the common special case when there is one audience, the aud value MAY be a single case sensitive string.

I removed audience and just have client_id now. I'm thinking that if someone wants to require an extra audience then they can validate that with a custom IDToken model

[samedii]

I tried to get everything in here before publishing fastapi-third-party-auth but there are some issues that I found after doing the renaming. I can probably resolve this by doing some cherry picking / rebasing

[HarryMWinters]

@samedii I think there's a few unresolved comments but nothing that should take very long. I'm happy to take on some of the work or I'm sure you could wrap it up quickly if you have time.

Once this is merged I'm going to play around a bit with the tagging workflow but I imagine we should be able to publish quickly.

Anyways, let me know what you think.

Cheers

[HarryMWinters]

Bump @samedii Are you still interested in merging this? Or would it be better if I took it over?

[samedii]

Sorry I've had too many other things that are higher priority since we are using the other published repo at the moment and it's working. It would be nicer to migrate to fastapi-oidc and have a common codebase instead

The merge is a bit messy since master is another 5 commits ahead.

I think maybe taking a look at one small thing at a time might be the most viable.

[samedii]

Only have a few commits left to cherry pick from. Will finish it tonight.

[francbartoli]

Hi @HarryMWinters and @samedii, I'm using fastapi-third-party-auth but I'm pretty much happy to switch to fastapi-oidconce this will be merged. So thanks a lot guys for these great packages! I'm just wondering if this will happen soon.

Also, one additional question: is the PKCE mode supported in the authorization code flow? Is it something of interest to support? May I help somehow?