-
Notifications
You must be signed in to change notification settings - Fork 103
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for firebase kid:key maps. #30
Comments
* Enhancements * Add support for decoding firebase certificate public keys (thanks to @noizu, see #30) * Fixes * Fix cross-platform issues with EC signatures (specifically S and R sizes, thanks to @alexandrejbr, see #32) * Typo in documentation for `JOSE.encode/1` (thanks to @DaveLampton, see #31) * Tests * Tested against OTP 19.3, Elixir 1.4.x, and Poison 3.x
@noizu The API is still a little clunky (I couldn't find any reference anywhere for the "standard" that the firebase keys are in. The ["Bearer " <> token] = get_req_header(conn, "authorization")
kid =
try do
token
|> JOSE.JWS.peek_protected()
|> JOSE.decode()
|> Map.get("kid")
catch
_, _ ->
nil
end
{:ok, {{_, 200, _}, _, body}} = :httpc.request(:get, {'https://www.googleapis.com/robot/v1/metadata/x509/securetoken@system.gserviceaccount.com', []}, [autoredirect: true], [])
firebase_keys = JOSE.JWK.from_firebase(IO.iodata_to_binary(body))
case Map.get(firebase_keys, kid) do
jwk=%JOSE.JWK{} ->
verified = JOSE.JWT.verify_strict(jwk, ["RS256"], token)
_ ->
# handle invalid token or kid
end |
Yes, google kind of decided to go it alone in their implementation instead of following best practices .etc. Which is kind of how google seems to operate these days. Too many PHDs not enough engineers. The token is base64 encoded with the first part indicating the current kid being used, they provide an api with current keys which slowly rotate over some period of time. Aka they return ~4 or so keys and i assume eventually dequeue and queue off the old and new keys so that there's a hour or so window in which you'll be able to look up the key. I use rather inelegant hack of the uberauth verify_headers behaviour to handle authorization. Although I'll need to clean this up to take advantage of your latest revision. If anyone else finds themselves dealing with googles nonsense this is what I currently use (worts and all). (I keep keys cached to avoid the need to constantly ping google's endpoint per request with some cache busting logic and rate limiting threshold of 5 seconds to avoid a disfavored or misconfigured user from being able to cause my backend to endlessly request key updates. I'll follow up when I get the chance to refactor this a bit more to help anyone else down the road that has to handle firebase auth from elixir.
|
Google serves firebase keys in a somewhat nonstandard form.
#{kid := key}
https://www.googleapis.com/robot/v1/metadata/x509/securetoken@system.gserviceaccount.com
It seems that many jose implementations, have made allowances for this structure and when passed a map of keys correctly extract and verify a firebase token using this data structure.
e.g. http://stackoverflow.com/questions/40839874/how-to-decode-firebase-jwt-token-in-python
along with some php and node and I suspect others.
Although it's a little nonstandardized putting up some docs or possible code changes for handling firebase certs will probably save some people a bunch of time down the road.
Additionally I was unable to use from_pem calls to prepare keys from the the google RSA certificates. Although possibly this was due to user error. This forced me to manually extract the certificates using :public_keys and logic derived from from https://codegists.com/snippet/erlang/jwterl_ahmadster_erlang
before passing on to JWK (below code snippet).
From_pem failed due to a inability to match the decoded record to a from_key call in
jose_jwk_kty.erl
The text was updated successfully, but these errors were encountered: