App login and authentication should generally be done in the form of JWTs.
JWT’s are used as a form of Single-Sign-On to use your current authentication mechanism to verify the identity of a user.
The general premise is that as a partner, you will send a json dictionary of claims about the currently logged in user as well as a cryptographic signature verifying that you verify this information is correct. This JWT claim should be created server side within your application’s login infrastructure to ensure that users can not impersonate each other
Further documentation on the JWT standard can be found at jwt.io
VouchrSDK Support
VouchrSDK currently supports 3 different types of signatures, configurable through your dashboard.
- Public Key Signature (via RSA, we support RS256, RS384 and RS512)
- Shared Key Signature (via HMAC, we support HS256, HS384 and HS512)
- Unverified (via NONE, useful for testing, but should never be used in production)
You also need to define a Network Id (name) in the dashboard that will be used to reference these settings
Supported basic claims include:
- “sub” (REQUIRED) subject - may be username, email address or account/surrogate id
- “aud” (OPTIONAL) audience - should be ‘Vouchr’
- “iss” (OPTIONAL) issuer - should represent the partner/issuer involved
- “nbf” (OPTIONAL) not before - timestamp in seconds that the token is not good before
- “exp” (OPTIONAL but recommended) expiry date - timestamp in seconds is not good after
- “iat” (OPTIONAL) issued at time - timestamp in seconds at which the token was issued
- “jti” (OPTIONAL) jwt id - used as a nonce preventing the same signature from being used twice
Supported extended claims include
- “first_name” (OPTIONAL) - first name of logged in user, used in presentation of gift to recipient
- “last_name” (OPTIONAL) - last name of logged in user, used in presentation of gift to recipient
- “email” (OPTIONAL) - used to indicate the email address of the recipient
- “email_verified” (OPTIONAL) - used to indicate that you as a partner verify the ownership of said email
Note that if you are implementing the ‘claim’ portion of the sdk natively and gifts are received via email, then email and email_verified must be specified for those gifts to show up when the user logs in. (or the recipient email needs to be verified in some other way)