Skip to content

Proposal: rename Login and LoginStorage to Session and SessionStorage #39

@ThisIsMissEm

Description

@ThisIsMissEm

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions