CODEWITHSUNDEEP
authenticationclient
Li Haoyi
Li Haoyi

Reputation: 15812

Authentication for in-browser client-side APIs?

I'm thinking of the Google Static Maps API, which limits you to 1000 static maps, more if you sign up for an account. How do they keep track of accounts and such, when everything on the client is public?

For most server-to-server APIs I am given a access_token/key/etc. which I can pass to the service to prove that I am indeed me, but on the client any such access_token/key/etc. would immediately become public knowledge.

In general, what strategies to client side libraries (FB SDK, Stripe, Google, etc) use to perform authentication, and how do they get around the fact that everything on the client is public?

Upvotes: 4

Views: 436

Answers (1)

Tass
Tass

Reputation: 1248

You can configure your API key to whitelist by host which tells Google Maps to only allow the API key to be used from a site sending a referrer that matches your whitelist.

If some other site uses your API key, they'll get this error message on load:

This web site needs a different Google Maps API key. A new key can be generated at http://code.google.com/apis/maps/documentation/javascript/v2/introduction.html#Obtaining_Key.

You can verify this yourself by using the RefControl extension for FireFox:

This works because:

  • Practically all web browsers send a referrer (i.e., the URI of the resource which links to it) as part of a request.
  • For someone to steal your API key (since as you say, it's a publicly available string), they would need to tell all their users to override their referrers to match the site they stole it from (which clearly isn't practical).

Note that Google seem to allow requests that contain no referrer - I guess the amount of browsers that are configured to exclude this information is minuscule and therefore not worth caring about.

Upvotes: 1

Related Questions