The way Matrix treats authentication is interesting, and perhaps something we can use in the Federation - matrix.org 
The homeserver may provide many different ways of authenticating, such as user/password auth, login via a social network (OAuth2), login by confirming a token sent to their email address, etc.
This specification does not define how homeservers should authorise their users but instead defines the standard interface which implementations should follow so that ANY client can login to ANY homeserver.
The process takes the form of one or more stages, where at each stage the client submits a set of data for a given stage type and awaits a response from the server, which will either be a final success or a request to perform an additional stage. This exchange continues until the final success.
Authentication works by client and server exchanging dictionaries. This specification covers how this is done over JSON HTTP POST.
For each endpoint, a server offers one of more 'flows' that the client can use to authenticate itself. Each flow comprises one or more 'stages'.
Flows may have more than one stage to implement n-factor auth. When all stages are complete, authentication is complete and the API call succeeds.
To establish what flows a server supports for an endpoint, a client sends the request with no authentication. A request to an endpoint that uses User-Interactive Authentication never succeeds without auth.
Homeservers may allow requests that don't require auth by offering a stage with only the m.login.dummy auth type. The homeserver returns a response with HTTP status 401 and a JSON object as follows:
{ "flows": [ { "stages": [ "example.type.foo", "example.type.bar" ] }, { "stages": [ "example.type.foo", "example.type.baz" ] } ], "params": { "example.type.baz": { "example_key": "foobar" } }, "session": "xxxxxx" }