3rd party auths

[rragundez]

First of all this is so good! I don't know why i did not came across it before :)

Is your feature request related to a problem? Please describe. Nowadays is quite common to use 3rd party auths, like EntraID with Microsoft, Google, Github, etc. I think they are not that many and in my experience once the auth is done it doesn't really have to change so I think is good to add as a template and then maybe allow the developer to activate it via en environment variable

Describe the solution you'd like Add endpoints to the backend for each provider such as /login/provider /callback/provider and manage the parsing of the access token to get or create a user and then create a JWT token using the already including functions. Then allow the configuration to be defined such that either in environment variables or similar, we can define which auth/auths to use (google, microsoft, github, native)

Additional context Perhaps context, is that in my experience by adding this it will enable more enterprise ready applications where setting auth is very important to get correct.

If you think it would be helpful, I could create a PR.

[carlosplanchon]

Hello!, I agree with you suggestion.

I think this can be done with FastAPI-SSO. https://github.com/tomasvotava/fastapi-sso

[igorbenav]

It definitely would be helpful, @rragundez, feel free to create a PR! We'll very much appreciate

[igorbenav]

@rragundez do you want to do it? @carlosplanchon can help

[rragundez]

@rragundez do you want to do it? @carlosplanchon can help

I can get the first PR started with the basics oauths. Then I would suggest to re-assess how to use the new information coming from the response for the benefit of the user, like role assignment, email, profile picture, etc.

[carlosplanchon]

@rragundez, please, enter the Discord, because with fastapi-sso I already have existing code you can just reuse. So... that + Claude Code may just reduce the amount of work needed.

[rragundez]

@carlosplanchon I don't mind the work, I like it. I just need some guidance on how you guys want to implement it. Do you want me to just make an opinionated PR or to check with you before hand make some decisions? For example:

• When using oauth, then the hashed password value can be null or a random password, a random password is by far easier as it matches the current mechanism, setting it to null is a better practice but requires more changes in the DB schema but also in the authenticate_user function.
• Do you want the application to be quite flexible such that a user can login in several ways (local auth, google, microsoft)? and then having the identifier in the DB being via their email? or to allow single way of logging in (google for example) for the whole application lifetime (this is the most common in enterprise applications).

For now I'll make a PR with what I think is best. @carlosplanchon please share the pieces of code you might have, thanks.

[igorbenav]

Hey Rodrigo, in FastroAI I do something like this:

I treat each OAuth provider (Google, GitHub, Microsoft) as an implementation of the same interface. I have an abstract OAuthProvider base class that handles all the common stuff (generating secure state parameters, PKCE challenge codes, exchanging authorization codes for tokens, and fetching user info). Then each provider just implements the specifics like their endpoints and how to parse their user data. Adding a new provider is just creating a new class and registering it with a factory. So when someone needs LinkedIn or Discord OAuth, it's maybe an hour of work instead of redesigning everything.

I handle account linking by always checking the email first - if an account exists with that email, I link the OAuth provider to the existing account. This means users can sign in however they want and it just works. For username conflicts, I do the progressive numbering thing. If "john" is taken, try "john1", then "john2", until I find an available one. Not fancy but it prevents signup failures (people can just change the username later, but singing up doesn't fail).

I use PKCE by default, store OAuth state in Redis with automatic expiration, and validate everything properly. Plus I can add custom claims or modify the flow for specific enterprise requirements. OAuth requires you to generate a random state parameter, store it temporarily, then validate it in the callback to prevent CSRF attacks. I use Redis with a 30-minute expiration and include the PKCE code verifier in there too.

But honestly, fastapi-sso might be the smarter choice here. It's battle-tested and handles all the provider quirks.

The basic integration looks something like this - you create provider instances with your credentials, then have login endpoints that redirect to the OAuth provider and callback endpoints that process the response. FastAPI-SSO handles all the OAuth complexity and just gives you the user data.

You'll still have to deal with account linking though. You'd need to check if a user with that email already exists, handle username conflicts, and decide whether to merge accounts or create separate ones. But the OAuth protocol itself is handled for you.

Start with what you want, we can always adapt the implementation later. Just stick with /auth/login/{provider} and /auth/callback/{provider} for urls.

[carlosplanchon]

Okay, as we were talking on Discord, @rragundez, this may be also thought as an extension. I'll be writing a draft about this point shortly.

[carlosplanchon]

Extensions Spec first draft:

https://github.com/benavlabs/FastAPI-boilerplate/issues/221

@rragundez

[carlosplanchon]

Based on that spec, a possible structure for fastapi-boilerplate-sso (with Claude Code):

This library:

• uses fastapi-sso to handle the OAuth/OpenID protocol for providers (Google, GitHub, Microsoft, etc.),

• isomorphic to the existing auth system:

  • same User model,
  • same token creation functions,
  • same login result (JWT access/refresh + cookies),

• lives in a separate package, e.g. fastapi-boilerplate-sso.

High-level structure:

fastapi-boilerplate-sso/
└── fastapi_boilerplate_sso/
    ├── __init__.py              # SSOSettings + register_extension
    ├── settings.py              # Google/GitHub/etc settings
    ├── models.py                # OAuthConnection, OAuthState
    ├── schemas.py               # OAuthUserInfo
    ├── providers/               # GoogleProvider, GithubProvider, ...
    ├── manager.py               # SSOManager (link or create user)
    ├── router.py                # /sso/{provider}/login + /callback
    └── ...

This extension:

• mirrors the existing login mechanisms (isomorphic design),
• reuses the project’s User model and JWT machinery,
• and remains an optional external package, installed via pip.

@rragundez