Create a LoginManager object which provides a model for managing authentication

[sirosen]

Summary

The SDK only defines helpers and tools for authorization, not authentication.

We want to provide an interface consisting primarily of two activities:

• Do a Login Flow
• Get Credentials From the Last Login Flow

Prior Art (CLI)

In the Globus CLI, we have a LoginManager object which covers several needs which we have in this context.
Specifically, this is what we have there:

• a requires_login decorator which can enforce that either credentials are present for a given scope or an error is raised
• an interface for initiating login flows, either the text link flow or the local server flow
• client builder methods, e.g. LoginManager.get_transfer_client

The LoginManager abstracts over tokenstorage, it builds the correct authorizer objects (pointed back at the tokenstorage), and then it uses those authorizers to build clients. It also tracks static and dynamic scope requirements for the CLI, allowing it to be used implicitly to login with some default requirements or explicitly to handle GCSv5, individual Flows, and explicit scopes (globus session consent).

Requirements

• The LoginManager should contain a tokenstorage object for holding credentials.
• It should provide helpers for getting either clients or authorizers from those credentials
• It should gracefully allow for changes to the scopes needed for a service (NOTE: not currently handled in the CLI)
• It should support the text-based login flow (globus login --no-local-server) out of the box
• It should be usable in the SDK tutorial and examples
• It should allow for customization of the client classes used (e.g. custom subclasses)
• It should know the scope-to-client association already present for Globus services
• It should support the local-server CLI login flow as a customization applied by the CLI but it should not implement this in the SDK for a first version

Custom login flows are a particular area of interest. I think (at time of writing) that the best interface will be composition, as in

• A LoginManager has a LoginFlowProvider
• The default LoginFlowProvider is a InteractiveTextLoginFlowProvider
• A LoginFlowProvider can be altered or configured when running a login flow, either imperatively right before the flow or with some callback or other mechanism

Open Questions

• Does this object provide back authorizers, clients, or both? What are the interfaces for doing that?
• How are login flows exposed?
• How are the login requirements injected into or attached to a login manager?

Implementation Plan

As a potential path forward, we have discussed writing a spike and trying to use it to reimplement the CLI functionality.

The prototype can either be included in a branch here or in the CLI, and then used to "reason backwards" towards a publicly usable interface.

[pka420]

Currently we start the oath_flow and get authorize url, go to browser fill in our credentials and then exchange code for tokens.
If I am getting this right, LoginManager will be able to skip these steps and just do the login directly from command line.

This will be great once implemented, then we can run some jobs in cron, without having to login everytime.

Thinking how will one go about implementing it without having to open the browser and exchanging code for tokens.