-
Notifications
You must be signed in to change notification settings - Fork 200
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OAuth / API Token Support #779
Comments
Im thinking of this from 'outside in' like how this would work from a user's perspective before diving into the the technical implementation. Im currently basing the design of this feature off of how grafana has implemented authentication Here's some docs from grafana: ConfigHere's what their default config looks like for auth, we would use YAML instead, maybe adding TOML support for config would also make sense as an additional feature? For Flipt I'm thinking the config could look like this: auth:
anonymous:
enabled: true # default since Flipt doesnt have auth now
github:
enabled: false # default
allow_sign_up: true
client_id: some_id
client_secret: some_secret
scopes: user:email,read:org
auth_url: https://github.com/login/oauth/authorize
token_url: https://github.com/login/oauth/access_token
api_url: https://github.com/gitapi/user
allowed_domains: # csv of allowed domains of user emails on GH to enforce user is part of org
gitlab:
enabled: false # default
allow_sign_up: true
client_id: some_id
client_secret: some_secret
scopes: api
auth_url: https://gitlab.com/oauth/authorize
token_url: https://gitlab.com/oauth/token
api_url: https://gitlab.com/api/v4
allowed_domains: # csv of allowed domains of user emails on GL to enforce user is part of org If anonymous was |
Yeah, love that format! From the user perspective, some sort of support for environment variables for the secret (at least) would be necessary. The scheme you use now where that's prepended with FLIPT_ would work perfectly. So, you'd end up with In fact, I wonder if that convention could be used for the entire configuration. So you could provide the auth setup entirely from the environment. If nothing else, that'd be really nice for a docker image example with auth enabled. As a more advanced feature, you could use some templating in the YAML and then pull the value when the config is parsed. |
yeah, currently every config key/value in YAML can also be set via an ENV var with the |
Alright so I'm starting to think through the backend/frontend flow Frontend/Backend flow
Database
Actually the more I think about it we will need to persist users to support access tokens created by users, unless we just want to make access tokens global that can created by anyone with no owner For DB I actually think we'll only need a
|
column | type | comment |
---|---|---|
id | VARCHAR(255) UNIQUE NOT NULL | primary key, chose varchar so we could use uuid's to be consistent with existing |
VARCHAR(255) UNIQUE NOT NULL | ||
name | VARCHAR(255) NOT NULL | do we need name? maybe for future audit log support? |
enabled | boolean | prob wont be used right now, but it might be nice for admins to be able to disable users in the future? |
created_at | TIMESTAMP NOT NULL | |
updated_at | TIMESTAMP NOT NULL |
Pretty simple to start
For the flow, is this going to be using a standard authorization code grant type? If it is, I think it's going to be more like:
If we don't want to do the cookie step, the JWT could be stored in application storage. The DB schema looks good in principal, but my few thoughts: I'm on the fence about name. When I've previously implemented oauth, I was very careful to only ask users for information I absolutely needed to make the app work and for name, I feel like YAGNI. Another thing I'd think about is account linking. The underlying user is a Flipt user that has a Flipt ID. So, when somoene logs in with GitHub and they have the email
Then that table can be used whenever a login happens and you want to associate a provider ID with a Flipt user. |
@tsickert yeah 💯 . I mixed up/left out a few steps. You're right the request would go to the provider then redirect back to us on the backend. I was wondering how we would handle the case you mentioned about a user being created in the system and then authing with multiple providers. I think a join table makes a lot of sense like you described. I also agree that we can leave out name for now as its probably not needed. tl;dr: yes to everything you said |
So, what's your vision for how the authz flows work? I was thinking about it, and there's sort of a chicken and egg problem. Let's assume that the portal is deployed but is not inside a VPC or it's behind a cloudflare WAF that's misconfigured so it's accessible. How would the administrator be able to manage which accounts should actually have those In fact, we'd need to have an administrator account, right? Or at least a way to set which account would be an administrator. My first thought is that the oauth configuration could have an After that, accounts that sign up would probably need to be validated by an admin, or maybe we could provide some wildcarded field to automatically assign people with Thoughts? |
I was thinking that the Ex: Only users whose GitHub or Gitlab emails end in Now this has the potential issue that all Oauth providers would need to verify a user's email before actually returning it as a valid email when getting the user info via their APIs. I'm pretty sure GitHub does this , but we'd need to double check, and also check that GitLab does the same |
Also Id like to add a 'Securing Flipt' guide to the docs when this is rolled out, detailing some best practices, ie: flipt config shouldnt be accessible/writable by non-trusted users, etc |
I think the Securing Flipt guide idea is really good. Yeah, the email thing does feel fragile now that you mention it. It doesn't seem reliable given that some accounts are by phone number rather than email. While the We might need to make more complex rulesets eventually--something like: allowed_user_filters:
- type: email
patterns:
- someuser@gmail.com
- '*@foo.bar'
- type: phone
patterns:
- 123-456-7891
- type: id
patterns:
- 123456789 |
Yeah I can see that, however Im not trying to solve every potential use case at the moment without feedback from users. So I'd rather start with the same approach that grafana uses (allowed_domains), maybe structure it similar to the above so really just support the single basic email filter at first |
Yeah, you're right, I'm probably over engineering it for the first pass 😅 Putting my customer hat on for a sec: I will say that I use my personal gmail account for my GitHub, so |
Thats a good point. What about instead of email, we use Actually, re-looking at the grafana GitHub Oauth docs it looks like they support both |
Oh, I totally missed those before. Those would be perfect! I also agree that having that object hierarchy is probably preferrable to everything at the top level. |
👋 Just throwing in two cents here. Went through something similar recently (JWT-based auth for session logic). OWASP advises the This protects consumers with client-side vulnerabilities from accessing the contents of the cookie via the DOM. This should not be a problem if you just drop that step. The JWT is in the Another thought, JWT is very unpopular for session logic currently. The arguments against are usually around the (in)ability to manually invalidate a particular session. The first result when you Google "JWT for session management" is: The result often ends up being that you need to some backend storage, which stores the IDs for the token you want to be invalidated. Which means you have to do a lookup on each session in a DB anyway. To find out if the session has been invalidated. You have to store these at-least until they expire naturally, due to the Ultimately, you could argue you might as well have some backend session storage, somewhere. Just something to consider. JWT (for sessions) is still valid, and can ultimately be done securely. |
Follow-up suggestion would be to do OIDC. OAuth is historically for delegation of authorization specifically. Supporting this would open doors to like Okta, Auth0, ORY, Dex and other OIDC providers. |
I think we'd like to support 2-3 logins via external identity providers out of the box, ranked in order of (my) perceived need:
I dont believe GitHub supports OIDC for login directly, although it seems Google does. But I do agree that supporting OIDC would be ideal, I guess that means we'd still need to support GitHub separately? |
Yes, Google does. Perhaps doing Google via OIDC would be a beneficial endeavour. That sounds like a sensible three to start with 🎉 Pointing back to Grafana as a source implementation, here is their "Generic OAuth" impementation. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
We have support for OIDC and token authentication as of |
So is GitHub auth not included in this OIDC capability? I don't believe GitHub provides OIDC support and that seems to have been forgotten here |
Hey @endigma . You are right that Github doesn't support OIDC. |
We don't have any other suitable auth provider in our org, so very much so yes. |
@endigma we will prioritize this! I think it might unlock some other nice integrations with GitHub down the road, but Oauth support for GitHub is a first step/requirement! |
#2004 for tracking |
Hey @endigma , we just released this in https://github.com/flipt-io/flipt/releases/tag/v1.26.0, working on updating the docs now! let us know how it works for you 🎉 |
This issue is to track/help define adding OAuth (and likely API Token) support in both Flipt backend and Flipt UI. This will allow users to login to Flipt via existing third party services as well as provide basic auth for API requests.
My initial thoughts for this feature are:
client_credential
OAuth Grant type, we'd need a way for API requests (REST/GRPC) to also support auth without a user being present. We could add the ability for users to create API tokens for the machine to machine usecase (your app <-> Flipt). We could also implement scopes for these API tokens such as (management, evaluation) and TTL so that users could limit what these tokens could do.Further design docs/diagrams/potential DB schema will be added below.
The text was updated successfully, but these errors were encountered: