Sender | Message | Time |
---|---|---|
23 Mar 2024 | ||
Brynn | its a good pattern. | 07:18:50 |
25 Mar 2024 | ||
@tomz_plug:matrix.org left the room. | 15:38:07 | |
26 Mar 2024 | ||
Brynn | Should I assume that asking for oauth consent just once requires the config database for oidc? I see implict, explicit, auto, and pre-configured. It would be nice to ask the first time then not ask again. | 20:15:15 |
James | That's the pre-configured option. The user can pre-configure consent for the requested client id + scope + audience option. | 21:43:47 |
James | via a "remember" option. | 21:44:00 |
Brynn | Apologies, I probably should have asked in support. Is there an existing way to ask the user once and remember forever? | 21:45:53 |
James | No and there wont be one | 21:46:23 |
James | You can configure the pre-configured duration however you want | 21:46:43 |
James | But the user has to provide consent and consent to remember the consent | 21:46:58 |
James | If they provide the consent to remember it then that specific consent scenario will be remembered for the duration configured | 21:47:21 |
Brynn | Oh, I just realized that's probably against standards. Its bad to never rotate secrets. | 21:47:23 |
James | Yeah the spec allows for pre-configured consent but has wording from memory which indicates that the user must explicitly consent to remember it | 21:48:23 |
James | * Yeah the spec allows for pre-configured consent but has wording from memory which indicates that the user must explicitly consent to pre-configure it | 21:48:33 |
James | * No and there wont be one most likely | 21:48:53 |
James | * No and there probably wont be one | 21:49:02 |
James | In addition if the client ID, scopes, or audience change the user must provide consent again | 21:49:34 |
Brynn | Only reason I'm asking is that Google oath (to my knowledge) never asks again for consent for a specific oath service. | 21:49:57 |
Brynn | IE once you give consent to use your Google account, you never get asked again. Unless I'm misremembering. | 21:52:36 |
James | That's a pre-configured consent | 21:54:16 |
Brynn | Oh! Ok I got it now. I wasn't equating creating the config for authelia with accepting consent the first time on Google. | 21:55:50 |
James | Think of consent like this, the user is providing consent for the client to access information known about them via the resource servers API in this case the /api/oidc/userinfo endpoint, using the provided tokens. The information the client is allowed to access is part of the consent process. The only difference between what Google does and us is we give the admin choice to enable pre-configurations, and the user has to explicitly allow implicit consent for the consent in the future (via the remember option). | 22:00:49 |
27 Mar 2024 | ||
Brynn | In reply to @james:authelia.comYou mention an interface to get oidc client info. Would you mind pointing that out to me? | 06:08:47 |
28 Mar 2024 | ||
Brynn | Download image.png | 01:55:46 |
Brynn | overall format shamelessly stolen from the existing user settings pages. | 01:56:32 |
Brynn | not sure how to format the content/which content should actually be shown | 01:56:59 |
James | I'm rather flat out but will get back to you soon | 02:22:39 |
Brynn | hey no problem. Everyone is entitled to be busy. | 02:23:08 |
James | In reply to @crowley723:matrix.org
| 22:58:29 |
James | We can adjust the NewStore signature to take a ClientManger and implement two, one in-memory like it is now, and one in SQL. | 23:00:59 |
James | Here's an abstraction that makes this easier, we just need to ensure we add a StorageClientStore and accompanying NewStorageClientStore: https://github.com/authelia/authelia/pull/7041/files#diff-33477abe4b572dab542eab82c130a0e4625cd907c0c4a9ca92e5c62852706433R24 | 23:13:17 |