jose-jwt | Ultimate Javascript Object Signing and Encryption (JOSE), JSON Web Token (JWT) and Json Web Keys (JW | Authentication library

The answer is to use String for (de)serialization for those facing this problem. Why, you ask? According to the RFC, JWK is a string in the JSON format. While nimbusds:nimbus-jose-jwt defines a JWK object, any APIs that return valid JWK (or JWKSet) can assume that it's a string.

I also raised this issue with the developers of this package, and they recommended using String or Map for (de)serialization.

You need to expose an API scope in Azure, and get the client to use that. Also ensure that there is no nonce field in the JWT header of the access token. My blog post has further info.

AZURE AD BEHAVIOR

The above behavior is quite specific to Microsoft, and is required when using Azure AD as a provider:

• Tokens with a nonce field in the JWT header are designed only for MS APIs, eg Graph, and use an in-house validation mechanism. The intent is for these to always fail validation in custom APIs.

• Tokens for your own custom APIs must be retrieved via clients that request custom scopes. Note that the OAuth client configured in Azure AD can be a logical entry, rather than needing to maintain one for each individual API.

I believe the MS behavior is based on OAuth resource indicators, though my personal preference is to use more mainstream techniques of scopes, claims and audience checks when receiving access tokens in APIs.

Your error is stating that you are attempting to use a class which does not exist. If it works locally and it does not work on Google Cloud, that means the libraries/jar are not configured properly.

If what you are deploying is a Fat/Uber jar, unzip the jar and verify the location of nimbus-jose-jwt.

An uber JAR is a JAR file that contains the function classes as well as all of its dependencies. You can build an uber JAR with both Maven and Gradle

If what you are deploying is a Thin Jar, ensure that your dependencies are in a package relative to the JAR deployed.

A thin JAR is a JAR file that contains only the function classes without the dependencies embedded in the same JAR file. Because the dependencies are still needed for deployment, you need to set things up as follows:

The dependencies must be in a subdirectory relative to the JAR to be deployed. The JAR must have a META-INF/MANIFEST.MF file that includes a Class-Path attribute whose value lists the required dependency paths.

The Google Cloud documentation is very clear on how you can use Maven/Gradle to deploy either.

https://cloud.google.com/functions/docs/concepts/java-deploy#deploy_from_a_jar

I can't believe I wasted two days straight on this because someone wrote the package with an uppercase letter. There was a class in a package :

Acording to this answer: https://stackoverflow.com/a/51236918/16651073 tomcat falls back to default logging if it can resolve the location

Can you try to save the properties without the spaces.

Like this: logging.file.name=application.logs

The problem was occurring because the default authentication manager wasn't working for me, I had to implement one specifically for my problem.

Turned out that there is a chance to debug Invalid credentials error for OAuth2 approach. After a suggestion from https://stackoverflow.com/a/62917085/10596295, I debugged the application and realized that there is a problem with the property user-name-attribute. My final version of application.yml looks like this:

The following should work:

The lifespan is the time after which the DefaultJWKSetCache will evict cached JWKSet. I.e., after lifespan time units passed since the cache was populated the calls to JWKSetCache.get() will always return null until new JWKSet is stored to the cache.

The refreshTime is the time that impacts value returned by JWKSetCache.requiresRefresh() method. After refreshTime time units passed since the cache was populated this method will return true, otherwise, it will return false. This setting does not impact cache behavior in any way.

The RemoteJWKSet uses the value returned by JWKSetCache.requiresRefresh() to re-download JWKSet from remote URL before the cache is actually expired. This is why documentation recommends to set refreshTime to a lesser value than lifespan.

Currently, RemoteJWKSet triggers download of remote JWKSet when either lifespan or refreshTime has passed (see this line.) Hence, there is not much difference in setting either one of these as of today. I guess some more complex logic can be potentially implemented having these two values separate.