Single sign-on (OAuth/OIDC) #63
Conversation
avdb13
force-pushed
the
single-sign-on
branch
3 times, most recently
from
aec1658 to
d383af1
Compare
| pub scopes: Vec<String>, | ||
| pub endpoints: Endpoints, | ||
| pub credentials: Credentials, | ||
| pub claims: HashMap<Claim, String>, |
There was a problem hiding this comment.
This allows flexibility for claims, claims are a hashmap of information about the user, returned in the token or userinfo response i.e. ("preferred_email" -> "[email protected]", etc.) and this will allow cases where we wanna point out that "preferred_email" corresponds to the Email claim in case of unconventional keys.
| pub credentials: Credentials, | ||
| pub claims: HashMap<Claim, String>, | ||
|
|
||
| pub code_challenge: bool, |
There was a problem hiding this comment.
| pub code_challenge: bool, | ||
| } | ||
|
|
||
| impl Borrow<str> for IdProvider { |
There was a problem hiding this comment.
The following impls are defined in order to prevent ID providers with duplicate IDs in the configuration.
| ) -> Result<Option<Account>>; | ||
|
|
||
| /// Find account by SSO ID | ||
| async fn find_account_by_sso_id(&self, idp_id: &str, sub_id: &str) -> Result<Option<Account>>; |
There was a problem hiding this comment.
Every token/userinfo response should have a subject claim which can be utilized to identify the user, in this case we need to know the idp_id i.e. Google/GitHub/etc. and the sub_id (should be serde_json::Value).
| } | ||
|
|
||
| #[derive(Debug, Default, Clone, PartialEq, Eq)] | ||
| pub struct SSO(HashSet<IdProvider>); |
There was a problem hiding this comment.
Is there a reason this isnt a HashMap? would remove the need for a custom Serialize, Deserialize and Hash impl
| pub struct SSO(HashSet<IdProvider>); | |
| pub struct SSO(pub HashSet<IdProvider>); |
|
|
||
| /// Save callback | ||
| async fn save_callback(&self, callback: &Callback) -> Success { | ||
| self.collection::<Callback>("callbacks") |
There was a problem hiding this comment.
This needs upsert to be set to true otherwise it will never create anything.
|
|
||
| /// Save secret | ||
| async fn save_secret(&self, secret: &Secret) -> Success { | ||
| self.collection::<Secret>("secret") |
There was a problem hiding this comment.
See before about upsert, however it would be better if this is hardcoded via a config value instead of being auto-generated and stored in the database
| .expect("server must have a URL"); | ||
|
|
||
| let callback_url = format!( | ||
| "https://{}/auth/sso/callback", |
There was a problem hiding this comment.
Its probably worth switching to using the host instead of the domain, and allowing ports and path.
|
If you are no longer wanting to work on this - i know its been a while, im happy to pick this up and finish it off, please let me know. |
Go ahead, there is very little work left, mostly regarding the changes you suggested. |
2 participants
This is a draft, a few things to consider:
authifieror only through the upstream ID provider?All I can think of for now. Refer to https://connect2id.com/learn/openid-connect and https://connect2id.com/learn/oauth-2-1 for implementation details.