Verification Flow
From the prior pages, you should now have the authorization code (32 byte hex) for the user.
// 32 byte hex string
async function myHandler(req: NextApiRequest, res: NextApiResponse) {
const code = req.query.code as string;
}You can now exchange the code and valid app configuration details. Be sure to keep the client secret secret. The response will contain all authentication details, including a verificationResponse.
Exchanging the Code
The next step is to exchange the code for authentication details. This is done via the exchange endpoint. This follows typical OAuth2 flow. You can also specify options to check the issued at time of code generation. Typically for in-person, you may need to disable the issued at time check of 10 minutes.
API Reference -> Exchange SIWBB Code
// 32 byte hex string
async function myHandler(req: NextApiRequest, res: NextApiResponse) {
const code = req.query.code as string;
const options = {
issuedAtTimeWindowMs: 1000 * 60 * 10, // 10 minutes (set to 0 to disable)
};
// POST https://api.bitbadges.io/api/v0/siwbb/token
const res = await BitBadgesApi.exchangeSIWBBAuthorizationCode({
code,
options,
grant_type: 'authorization_code',
client_secret: '...',
client_id: '...',
redirect_uri: '...', //only needed for digital immediate flow
});
const { address, chain, verificationResponse } = res;
if (!verificationResponse.success) {
console.log(verificationResponse.errorMessage);
throw new Error('Not authenticated');
}
//Verify claims or anything else you need to do here
}Access Tokens / Session Management
We return access tokens and refresh tokens for you to perform session management. The expiration times can help you implement sessions for your users, and you can health check the user hasn't revoked through the API. Code exchanges can only be performed once per unique code which is checked on our end.
Note this is not the only way of implementing sessions. You may implement custom approaches on your own like checking IDs, stamping hands, using claim numbers, etc.
https://github.com/trevormil/bitbadges-docs/blob/master/for-developers/sign-in-with-bitbadges/verification/api-access-tokens.mdVerifying Other "Attached" Criteria
For any other criteria like claim verification or attestations, you must check this additionally server-side. Do not trust that if you added claimId in the URL params that it is automatically verified.
Putting It Together
IMPORTANT: What is verified natively vs not?
Does check β
Proof of address ownership via their authenticated BitBadges account
Anything specified in the verify challenge options
Issued at time of code generation is not too long ago if options.isssuedAtTimeWindowMs is specified. Defaults to 10 minutes.
One exchange per authorization code -> access / refresh token
Does not check natively β
Additional app-specific criteria needed for signing in (claims, ownership requirements, attestations)
Does not natively prevent against flash ownership attacks, replay attacks, or man-in-the-middle attacks other than what OAuth2 protects against
Last updated