Implement your server-side endpoints
ownIdData
field you created in your database user table.
setOwnIDDataByLoginId
getOwnIDDataByLoginId
getSessionByLoginId
ownIdData
field.
Select the tab matching your server-side language in the sample templates below.
ownIdData
record for a given loginId
when the user enrolls a new device. This is the VARCHAR field you created previously. It holds the public key of the device used for biometric authentication.
setOwnIDDataByLoginId
)
ResponsesetOwnIDDataByLoginId
:
Status | Description | Return |
---|---|---|
204 | Request successful | return empty body |
ownIdData
record for a given user’s login id.
getOwnIDDataByLoginId
endpoint
Response
Implement these responses for getOwnIDDataByLoginId
:
Status | Description | Return |
---|---|---|
200 | User found and has ownIdData | return ownIdData String |
204 | User found but doesn’t have ownIdData | return empty body |
404 | User not found | return empty body |
token
is a unique session identifier that you generate. OwnID does not validate or use the token in any way, it merely passes the token back to you so you can identify the session it’s associated with.
Later, we’ll see how the OwnID login event returns this value in the frontend to establish a client session.
getSessionByLoginId
endpoint.
Response
Implement these responses for getSessionByLoginId
:
Status | Description | Return |
---|---|---|
200 | Request successful | return object or String (e.g: jwt) |
ownid-signature
, is a hash value that the OwnID server generates from a timestamp and the body of the request. The second one, ownid-timestamp
can be used by your backend to calculate the signature that is based on the timestamp and request body, and then compare the result to the value of ownid-signature
. If both signatures do not match, the request has been altered.
Because the signatures are generated using an HMAC with the SHA256 hash function, the OwnID server and your backend must use the same cryptographic key when calculating the hash value. You can obtain this key from the OwnID Console, and then add the code generates a hash and compares it to the signature in your backend.
Obtaining the HMAC Key
Before the backend can generate the HMACSHA256 value, you must obtain the secret cryptographic key used in the calculation. Simply open your OwnID application in the OwnID Console and copy the value from MyApp > Shared Secret.
Request Verification
Now that you have the cryptographic key, the backend can verify requests by generating each request’s expected signature and compare it to the one generated by the OwnID server. The backend code must:
ownid-signature
and ownid-timestamp
headers from the request. These headers provide the HMAC code generated by the OwnID server and the timestamp it used to generate it.
ownid-timestamp
for expiration.
To prevent replay attacks, check whether the provided timestamp is within an acceptable time window. Define a preferred expiration time, such as 1 minute, and validate against the current time. Requests with a timestamp older than this period should be rejected.
.
ownid-timestamp
header)ownid-signature
header.