Authentication
- Alice views a login form on a site or app and types in her username
- Alice clicks "log in"
- Alice gets a login request outside of the site or app (according to her preferences)
- Alice approves the login request
- Alice is logged in
Alice is redirected to her auth provider (which she specified in her profile information) then approves the request, then is redirected back to the app and logged in.
Alice is deep-link redirected to her auth app. She then approves the request on her app and gets deep-link redirected back to the original app and logged in.
Alice receives a push notification on the auth app on her device. It is routed through her auth provider which powers the push notifications for her auth app. She reviews the auth request, approves it, and is logged in.
If the app requires no data, Alice is simply logged in. Otherwise, Alice is shown a view where she approves the request and is logged in.
Alice is presented with a challenge message to sign. She signs it in her bitcoin wallet and then pastes it in the field and clicks enter.
Note: this is included mainly to demonstrate that the auth request handling could be done manually, in a similar fashion to http://bitid.bitcoin.blue/login.
- the app with a login view (the protected app) loads a library that generates the login form
- the user types the username into the form and clicks submit
- the protected app issues a call to the blockchain for the user's preferred auth type and auth details
- the protected app routes the auth request to the user
- the user reviews the auth request (the authentication app) and confirms or denies the request, signing an appropriate message to indicate the action chosen
- the user's authentication app delivers the response to the protected app's request
- the protected app receives the response to the auth request
- the protected app analyzes the auth response, then if the response includes a valid affirmation message, the user is logged in; otherwise, the user is denied entry
- the signing app reviews the signed auth request and determines the public key of the protected app
- the signing app looks up the public key in the blockchain and determines the identity of the app that corresponds to that public key
- the signing app shows the user the profile information associated with the public key (including the name of the app and the app's image) in order to give user confidence in the app that it's about to log into
- the protected app reviews the signed auth response and determines the public key of the signer
- the protected app looks up the username of the original user that attempted to log in and checks to make sure that the public key of the signing keypair is one of the user's authorized keys
- the protected app briefly displays the user's blockchain ID to demonstrate to the user that he/she was properly authenticated and the app knows who he/she is
- the protected app logs the user in
The protected app produces and signs an auth request message, then dispatches it to the signing app.
- host name (app domain)
- response URI
- user blockchain ID
- signature
Note: The user blockchain ID is included to communicate the app's intent/request to login a particular user. Keep in mind that some auth apps may have multiple identities.
- app name
- app image URI
blockchainID://?hostname=&responseURI=&userBlockchainID=&appName=&appImageURI=&signature=
Instead of providing an hostname, response URI, app name and app image URI, an app can provide an app blockchain ID, which the client can then use to lookup information about the app in the blockchain. This ensures that a given app has a consistent identity and doesn't try to send different information to different users. It also allows apps to verify domains, Twitter accounts, and Facebook accounts to provide additional trust.
blockchainID://?appBlockchainID=&userBlockchainID=&signature=
- signature
- requested user info
The protected app is required to have either an API endpoint or a form to submit
The protected app is required to have either a redirect endpoint to receive the response (in query parameters or POST data parameters) or an API endpoint to receive the response outside of a normal redirect.
The protected app is required to have either a redirect endpoint to receive the response (in query parameters or POST data parameters) or an API endpoint to receive the response outside of a normal redirect.
The protected desktop app is required to have an API endpoint to receive the auth response.
The protected app is required to have either an API endpoint or a deep-linking handler in the SDK.
The front-end SDK should be connected to the auth API endpoint via web sockets.
