Authenticating Users
Using REST API directly to sign in or up with Hyphen account.
Last updated
Was this helpful?
Using REST API directly to sign in or up with Hyphen account.
Last updated
Was this helpful?
Currently, Hyphen only supports Firebase Auth for OAuth 2.0 Provider. To add your own provider, please get in touch with us!
Request Firebase Auth to the user. The client will get a Firebase ID token.
In the client, check that the device key exists on the keystore.
If It does, go to A. Signing In with Challenge
Else, go to B. Signing In with 2FA.
Call Auth Request Challenge API. The client needs to send a request with the device's public key and the Firebase ID token.
If HTTP 200 -> The server will respond with random challenge data. Go to A.2.
If HTTP 400 with PleaseSignUp -> Go to C. Creating an Account.
Sign the Challenge Data with the Device Key. The client should request the device keystore to sign the challenge data received from the server. The data is hex-encoded but don't decode the hex before signing it— just sign the UTF-8 binary data directly. The signature should be ECDSA P-256 signature with SHA2-256 digest, encoded in IEEE P.1363 format (a.k.a. r||s concat format).
Call Auth Finish SignIn Challenge API. Send the signature along with the original challenge data. The signature should be encoded in a hex string.
If HTTP 200 -> Go to D. Finishing Authorization
If HTTP 400 with PleaseDeploy: The account contract needs to be set up on the chain you're using.
On the source device (i.e. who currently tries to sign in), It should request 2FA Sign-in.
Generate a Device Key. The device key needs to be stored on the device's HSM keystore, such as Secure Enclave or Android Keystore. The keypair should be ECDSA with P-256 (secp256p1) curve.
Call Auth Request 2FA API: Send a request with the device registration data, including the public key generated in the previous step and the push token of the device.
If HTTP 200 -> The server will respond with the 2FA request data. A push will be sent on the random device registered on the user's account.
On the other device which is selected for 2FA target, it should receive a Firebase push with the 2FA request data.
Request user's approval: Make sure that the client is displaying enough information for the user to know about the request.
If approves -> Go to step 2.
If denies -> Call Deny 2FA request API to cancel the request.
Send the transaction in the request using the device key.
Sign the payload in the request using the device key. Note that the payload is hex-encoded, so you need to decode it before signing it.
Call Approve 2FA request API: with the signature.
Close the screen.
Now go back to the source device. It will receive a foreground data push as the status changes.
Receive the silent push: 2fa-status-update.
If approved -> a transaction ID, credentials, and account info will be given. Go to step 2.
If denied -> Show the user an error message that the other device rejected the request.
Wait for the transaction ID to confirm. The transaction registers your new key to the account.
Generate a Device Key. The device key needs to be stored on the device's HSM keystore, such as Secure Enclave or Android Keystore. The keypair should be ECDSA with P-256 (secp256p1) curve.
Call Sign Up API. Send a request with the device registration data, including the public key generated in the previous step and the push token of the device.
If HTTP 200 -> Go to D. Finishing Authorization
If HTTP 400 with PleaseDeploy: The account contract needs to be set up on the chain you're using.
The server will respond with the credentials and account info.
Store the credential data in the local storage. The credential object consists of a JWT access token and a refresh token.
All done! The client can redirect the user to the home screen of your application.
Starts SignIn Challenge. This is required when the user is trying to sign in from the device already registered.
The client should request with the public key of the device. If it's not registered,
it will raise HTTP 400 with PleaseRegisterKey error.
Issues a random 32-byte challengeData to the client.
The client should respond by signing the data with the device's key, within 5 minutes.
The challenge type should be specified with either passKey or deviceKey.
/auth/v1/signin/challenge
deviceKey, passKeyThe public key of the PassKey in client-side. Should be 64-byte hex string concatenated with [x: 32byte, y: 32byte].
Finishes sign in challenge.
The client should provide the signature of the challengeData issued by the server.
If valid, it will return the API credentials and account information.
/auth/v1/signin/challenge/respond
deviceKey, passKeySign in with two-factor authentication from other device. This is required when the user is trying to sign on the new device.
/auth/v1/signin/2fa
Finish sign in after the user authorized the request on the other device. This API will return the API credentials and account information.
/auth/v1/signin/2fa/finish
The latest 2FA request ID.
deadbeef-dead-beef-dead-beefdeadbeefCreates new account and register the current device's key as the initial user key. This involves deploying the account on the chain you've specified.
/auth/v1/signup
The login channel the user is currently signing in/up.
firebasefirebase, testThe access token / ID token / redirect code retrieved as a result of OAuth 2.0 Sign In. Server uses it to call the OAuth provider to verify that the client correctly finished OAuth flow, and fetches users' basic profile information such as email.
Its value differs by channel:
apple, it's the ID token returned after finishing the SIWA process from the client.firebase, it's the redirect code from OAuth2 Redirect URI.eyJhbGciOiJIUzI...Qedy-rosPJLzs3jArh6Vcflow-mainnet, flow-testnet, ethereum-mainnet, ethereum-goerli, polygon-mainnet, polygon-mumbaiThe user key (usually device key / PassKey) created from the client SDK. Used as one of initial multi-sig keys for creating an account.