Browser tokens allow you to query the SEEK API directly from a hirer’s browser or mobile app. This can reduce the complexity and overhead of mediating SEEK API access through your software’s backend.
A browser token is scoped to a SEEK hirer and a set of actions that can be performed on the hirer’s behalf. Their restricted scope makes them safe to send to authenticated users of your frontend.
Our GraphQL schema supports browser tokens for features that can be used interactively by hirers. A query or mutation’s schema documentation will indicate which scope it accepts. If browser tokens aren’t mentioned the operation will only accept partner tokens.
When requesting a browser token you provide three parameters along with your partner token:
hirerIdis the SEEK hirer object identifier associated with your frontend’s user. The returned browser token will only be able to access data related to the specified hirer.
scopeis a space-separated list of permitted scopes e.g.
query:ad-products query:organizations. Each scope represents an action your frontend can perform with the returned browser token.Queries or mutations accepting browser tokens will indicate the required scope in their schema documentation . You can combine multiple scopes together to allow a browser token to be reused across different operations. However, including unnecessary scopes increases the security impact of a lost or compromised token.
userIdis a partner-specified identifier for the end user of your software.For effective tracking and debugging this should uniquely identify an end user. Do not include any personal information such as a legal name or email address. Instead, you can use an anonymous identifier such as a numeric ID or UUID assigned by your software.
Exchange a partner token for a browser token using
- Your frontend requests a browser token from your backend.
- Your backend authenticates its frontend user and finds the associated SEEK hirer.
auth.seek.comissues your backend a partner token.
- Your backend calls the browser authentication endpoint with the partner token and the request parameters.RequestCopy
POST https://graphql.seek.com/auth/token HTTP/1.1
Authorization: Bearer PARTNER_TOKEN_HERE
"scope": "query:ad-products query:ontologies query:organizations",
graphql.seek.comvalidates your relationship with the SEEK hirer and issues your backend a browser token.ResponseCopy
HTTP/1.1 200 OK
- Your backend returns the browser token to your frontend.Your frontend must cache the token for the number of seconds specified in the response’s
expires_in. The cache expiry must be read from each response; it cannot be hardcoded as the token lifetime is dynamic and may be updated without notice. Alternatively, you can use an
UNAUTHENTICATEDerror from the GraphQL endpoint to trigger a new token request. Caching browser tokens is important for frontend performance as requesting a new token can require multiple steps.
- Your frontend passes the browser token in the HTTP
Authorizationheader when making requests to the GraphQL endpoint.RequestCopy
POST https://graphql.seek.com/graphql HTTP/1.1
Authorization: Bearer BROWSER_TOKEN_HERE
Re-initiate the token exchange flow in the above section to obtain a new browser token. Note that this flow does not feature a refresh token.
Using a browser token right up to its expiry may lead to expiration occurring mid-flight due to clock drift or request latency. Consider leaving a reasonable buffer of around a minute, or obtaining a new browser token and retrying the request on an
You can use the
selfquery to return the associated SEEK hirer for a browser token. This requires that the token includes the
query:organizationsscope. If the token has expired the query will fail with an