I have a security question regarding using the Pick Widget.
I had assumed that if I supplied the data-fp-signature and data-fp-policy
I would not need to supply the API key.
When I don't supply the API Key I get the following JavaScript Error "Uncaught FilepickerException: API Key not found"
I have verified that my generated policy and signed policy match the filepicker.io test harness.
The API key is necessary for letting Filepicker.io who you are - the policy and signature are ways of verifying that you are who you say you ware, but you have to indicate who you are in the first place with your API key (for instance, so that we can look up your security secret and verify that the signature hash is correct)
Related
When building a Conversational Action with the new Actions SDK or Action Builder, you can define a webhook to handle business logic. This webhook then receives fulfillment requests with the following headers, among others:
Google-Actions-API-Version: "3"
Google-Assistant-Signature: "eyJhbGciOiJSUzI1NiIsImtpZC..."
How should that signature be verified? It's a JWT claim, but the key ID with which it was signed does not exist in the GCP account linked with the Action, and is not mentioned in the new Actions SDK documentation or in the Node.js fulfillment library documentation.
The signature is a JSON Web Token, which is an encoded way of transmitting some assertions that have been signed in a verifiable way. There are libraries that will both decode and verify JWTs. The general steps (some of which you can cache or shortcut) are:
Decode the header to get the kid (key id) and the payload to get the iss (issuer) fields. You'll also want the nbf (not before) and exp (expiration) fields to verify this was set recently and the aud field to verify that it matches your Google Cloud project ID.
Based on the issuer, access the well known openid configuration. Since the issuer is "https://accounts.google.com" you can access this at "https://accounts.google.com/.well-known/openid-configuration"
From the configuration document, you want the jwks_uri field, which is the URL to get the current JWT certificates. For Google, this is probably "https://www.googleapis.com/oauth2/v3/certs"
The certificate document should contain an array of keys. You want a key with the kid that matches the kid from the JWT. Note that these keys change frequently, but as long as you're within the window of the nbf and exp fields from the signature header, the key should exist in the certificate document.
With all this, you can then verify the signature portion of the JWT.
I've not been able to find decent information in the docs for this. Here's to the internet :)
This is my current understanding:
The documented approach is to create a ContentKeyPolicy with JWT restriction and Media Services will expect the claim added to the token of urn:microsoft:azure:mediaservices:contentkeyidentifier=INJECTED CONTENT KEY ID HERE based on what content the locator URL is serving up.
This means I'd need a new content key for every SKU sold to secure access to the media. Is there a way to hook into this authorization logic to say "I want you to call this API to run my custom validation" where I could check the JWT user's purchased content? This way only one content policy is really needed and becomes manageable.
The custom scenario you described is exactly the reason for using unique content key identifiers.
The way the key delivery server works with JWT tokens is that the key delivery server first checks to see which content key ID is being used. It then checks to see if the token is properly signed with the primary verification key that was used for that locator. Then it validates any claims that were applied when the encryption policies were set.
I'd recommend tracking the primary verification key (if unique per locator), the locator itself, the content key ID, and any claims in your own database so that all of those values are readily accessible for any of your content.
How does the generate-jwt policy work in API Connect? Does it invoke a authorization server in back end to generate the JWT? For example in real life scenarios, we have a authorization server which validates the user credentials and gives back the JWT which is n used in subsequent calls. But here i don't see any authorization server is needed we simply mention the claims the encryption algorithms and it gives back a JWT. Correct me if I am wrong.
Another related question:
I believe there are three possible ways to mention the secret to sign the JWT:
Private/Public key pair (RSA)
JWK
Shared Secret Key
How is the Shared Secret Key implemented in API Connect.
NOTE: I need to invoke a system which is exposed using JWT.
This policy does not invoke any authorization server. It only generates a JWT token, based on the input params that you provide. That authorization process should happen before the JWT generation.
The shared secret key in the policy can be provided in two ways:
a JWK: defining a variable with the JWK information
a Crypto Object: defined in datapower and referenced in the jwt policy
I'm implementing "Log In with PayPal" functionality. Should be fairly simple, but unfortunately PayPal lacks documentation (only some basic things are described).
I get authorization_code using "Log In with PayPal" widget. Than I make a request to https://api.sandbox.paypal.com/v1/identity/openidconnect/tokenservice and get JSON with access_token, refresh_token and id_token. I want to get unique user identifier, so I decode id_token, but I'm not able to verify signature of my id_token. Id_token header contains {"alg": "HS256", "typ": "JWT"}.
What secret should I use? Tried my app's secret (same that I use to access tokenservice), but it didn't work (using https://jwt.io/ debugger).
PayPal is not OpenID connect compliant. This answer explains the reasons.
PayPal expose a configuration endpoint - https://www.paypalobjects.com/.well-known/openid-configuration.It only support HS256 and does not support or mention about RS256. This could be due to a proprietary validation for ID token. For example a id token used as a bearer token.
Alternative solution would be to invoke userinfo endpoint as described by document. This endpoint can be invoked using access token and document says it would return the user_id
user_id - identifier for the end-user at the issuer.
Although it seems that user_id found in the userinfo is different from sub that could be extracted from id_token.
How to find public keys if signing algorithm is RS256
ID token is a JWT. As you have found out, it contains a JWS signature which acts as a MAC.
This signature is a signed using a private key. The receiver of the id token can validate the token using the public key. To find the public key, openid conenct specify a discovery document. You can read more about this from the specification
In the discovery document, you get a special endpoint to infer the configuration .well-known/openid-configuration. And one of the must have metadata of the configuration response is jwk_url
jwks_uri
REQUIRED. URL of the OP's JSON Web Key Set [JWK] document. This
contains the signing key(s) the RP uses to validate signatures from
the OP. The JWK Set MAY also contain the Server's encryption key(s),
which are used by RPs to encrypt requests to the Server. When both
signing and encryption keys are made available, a use (Key Use)
parameter value is REQUIRED for all keys in the referenced JWK Set to
indicate each key's intended usage. Although some algorithms allow the
same key to be used for both signatures and encryption, doing so is
NOT RECOMMENDED, as it is less secure. The JWK x5c parameter MAY be
used to provide X.509 representations of keys provided. When used, the
bare key values MUST still be present and MUST match those in the
certificate.
I am newbie in JSON web token and micro services. I read in an articles that if i share the private, all services can verify user on their own. Then i tried to implement an application to practice.
Basically, I have two services A and B. A is used for authentication. Then, I tried implement a API that required authentication in service B. But when I used a token generated by authentication A in API, 401 status code and "Invalid signature." were returned.
So anyone can explain to me what I did wrong?
"Invalid signature" implies that the secret key that you used to encode the token doesn't match with the secret key you used for decoding it.
Make sure that the secret you are using for encoding and decoding are same.
For more info visit the JWT's site.
First of all the service to service communication only need public key to be shared in case of an asymmetric key pair such as RSA or ECDSA. The public key shared can be used to verify the signature and each service needs to sign JWT using their private key. You have to take care of securing the private key and make public key accessible to other services.
Verifying the user is a completely different use case. The user existence should be checked in database and a password check can be made which is authentication is all about. The JWT can be used to pass the user information along with access right with a signature done by the application using private key so that no one able to generate the same token. NOTICE : Signature is done using private key. In this way you have both authentication and authorisation using JWT.