-
-
Notifications
You must be signed in to change notification settings - Fork 14
Description
Currently in the code, we use the structs Login and LoginStorage for persistence of the OAuth credentials (access token, refresh token, etc). The language of "login" can be somewhat confusing here, since they may not come from a login via a authorization code grant flow.
I'd like to propose renaming Login to Session, change issuingServer to issuer and adding a metadata dictionary (such that different implementations can store additional data with the session as required (e.g., Bluesky's sub property or handle for the account). Along with this, renaming LoginStorage to SessionStorage would ensure that people better understand what it's meant to be used for. LoginStorage should also support having the session be nil, rather than storing an invalid Session value.
In the internal interfaces, it would probably make sense to rename loginProvider to authorizationResponseProvider or something like that, to align with the OAuth language better.
These would be breaking changes, but would help make the code more understandable.
Additionally, having Authenticator's authenticate method return the current session post authentication would provide a clearer pattern for awaiting the session being established. Having a restore method would also allow you to take a Session from storage and attempt to restore it into an Authenticator — currently this happens implicitly on the first request made rather than explicitly, and can fallback to doing an interactive flow which may not be the intended user experience.
Splitting Token into AccessToken and RefreshToken would also be recommended, since currently refresh tokens don't really have a means to signal expiration (though this is currently being worked on in the OAuth WG with draft-ietf-oauth-refresh-token-expiration, which gives an expiry for the overall session, as well as for the refresh token in the token response.