Skip to content

Add extra fields support to oAuth AccessTokenResponse#5355

Merged
kaikreuzer merged 8 commits intoopenhab:mainfrom
lo92fr:features/oauth_token_extra_fields
Mar 10, 2026
Merged

Add extra fields support to oAuth AccessTokenResponse#5355
kaikreuzer merged 8 commits intoopenhab:mainfrom
lo92fr:features/oauth_token_extra_fields

Conversation

@lo92fr
Copy link
Copy Markdown
Contributor

@lo92fr lo92fr commented Feb 14, 2026

Add extra fields support to oAuth AccessTokenResponse

Description

This PR is about adding an extraFields maps in the OAuth AccessTokenResponse.
Some oAuth implementation return extra fields beside the accessToken/refreshToken/scope/state standard field.

With this change, this extraFields will be expose in the token response, giving a chance to use them.

The motivation beside this is for the new Smarthings Binding. Samsung oAuth implementation add en extra clientId field in the response, and I need to get this to handle smartthings stuff properly.

The changes are mainly in 3 files:

  • AccesTokenResponse.java to add the extraFields map.
  • A new AccessTokenResponseExtraFieldsAdapterFactory.java to handle decoding of extraFields from json response.
  • OAuthConnector to register the TypeAdapter on the gson object.

Signed-off-by: Laurent ARNAL <laurent@clae.net>
@lo92fr lo92fr force-pushed the features/oauth_token_extra_fields branch from 26292ff to 5cc0f43 Compare February 26, 2026 08:51
@wborn wborn requested a review from Copilot February 26, 2026 13:59
Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This pull request adds support for capturing extra (non-standard) fields from OAuth access token responses. This is necessary because some OAuth implementations, such as Samsung SmartThings, return additional fields beyond the RFC 6749 standard fields (access_token, token_type, expires_in, refresh_token, scope, state).

Changes:

  • Added an extraFields Map to AccessTokenResponse to store non-standard fields
  • Created AccessTokenResponseExtraFieldsAdapterFactory to handle custom JSON deserialization via Gson
  • Registered the new type adapter factory in OAuthConnector to enable extra field capture

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 11 comments.

File Description
AccessTokenResponseExtraFieldsAdapterFactory.java New Gson TypeAdapterFactory that extracts non-standard fields from OAuth JSON responses into a Map
AccessTokenResponse.java Added extraFields Map field with getter/setter methods to store additional OAuth response fields
OAuthConnector.java Registered the new AccessTokenResponseExtraFieldsAdapterFactory with the Gson builder

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Signed-off-by: Laurent ARNAL <laurent@clae.net>
Signed-off-by: Laurent ARNAL <laurent@clae.net>
@lo92fr
Copy link
Copy Markdown
Contributor Author

lo92fr commented Feb 26, 2026

Hello @wborn,

Thanks for the copilot review.
I've pushed the fixes for it.

Laurent.

Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 9 comments.


💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Signed-off-by: Laurent Arnal <laurent@clae.net>
@lo92fr
Copy link
Copy Markdown
Contributor Author

lo92fr commented Mar 5, 2026

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 9 comments.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Push the fixes this morning about copilot review of 1/03.

Laurent

@wborn wborn requested a review from Copilot March 5, 2026 16:39
Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.


💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

…nse::toString()

Signed-off-by: Laurent Arnal <laurent@clae.net>
@lo92fr
Copy link
Copy Markdown
Contributor Author

lo92fr commented Mar 6, 2026

@kaikreuzer, @wborn,

I think this could now be merged.

Thanks,
Laurent.

Copy link
Copy Markdown
Member

@kaikreuzer kaikreuzer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @lo92fr!
A few final review comments NOT coming from a bot, but from a person for a change. 😉

import java.util.Map;
import java.util.Objects;

import org.eclipse.jdt.annotation.NonNull;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you want to introduce null annotations with the new fields/method, you should make the whole class consistently use null annotations - and this means you should annotate it with @NonNullByDefault and then rather add @Nullable annotations at the appropriate places.

Comment on lines +247 to +248
* warning : the toString() function may returns sensitive information that should not go into the log.
*
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* warning : the toString() function may returns sensitive information that should not go into the log.
*
* Warning: the toString() function may returns sensitive information that should not go into the log.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

* specification. All unknown JSON properties are collected into a map and exposed via {@code extraFields} on the
* {@link AccessTokenResponse}.
*
* @author Laurent Arnal
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* @author Laurent Arnal
* @author Laurent Arnal - Initial contribution

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

lo92fr added 3 commits March 10, 2026 17:12
Signed-off-by: Laurent ARNAL <laurent@clae.net>
Signed-off-by: Laurent ARNAL <laurent@clae.net>
Signed-off-by: Laurent ARNAL <laurent@clae.net>
@lo92fr
Copy link
Copy Markdown
Contributor Author

lo92fr commented Mar 10, 2026

Hello @kaikreuzer,

I've pushed the fixes.

Laurent.

@lo92fr lo92fr requested a review from kaikreuzer March 10, 2026 17:17
Copy link
Copy Markdown
Member

@kaikreuzer kaikreuzer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Many thanks!

@kaikreuzer kaikreuzer merged commit 926304f into openhab:main Mar 10, 2026
5 checks passed
@kaikreuzer kaikreuzer added the enhancement An enhancement or new feature of the Core label Mar 10, 2026
@kaikreuzer kaikreuzer added this to the 5.2 milestone Mar 10, 2026
@holgerfriedrich
Copy link
Copy Markdown
Member

This PR has changed Nullable annotations in class AccessTokenResponse. The change is currently breaking the add-ons build.

Maybe you could comment if there a strong reason why all those methods now are retuning Nullable stings? I might have overlooked it in the discussion above.

grafik

btw: There is also a small inconsistency here, setTokenType requires a non-null string as argument.

Before creating a fix either on core or add-ons side, I would like to understand why this was changed. In general, we try to stay with non-null by default (with exceptions where Nullable clearly makes sense).

@lo92fr
Copy link
Copy Markdown
Contributor Author

lo92fr commented Mar 11, 2026

This PR has changed Nullable annotations in class AccessTokenResponse. The change is currently breaking the add-ons build.

Maybe you could comment if there a strong reason why all those methods now are retuning Nullable stings? I might have overlooked it in the discussion above.

grafik btw: There is also a small inconsistency here, `setTokenType` requires a non-null string as argument.

Before creating a fix either on core or add-ons side, I would like to understand why this was changed. In general, we try to stay with non-null by default (with exceptions where Nullable clearly makes sense).

Hello Holger,

Sorry for this.
This change was asked by @kaikreuzer because at first place, new extraFields was annotated with @nonnull

private Map<@nonnull String, @nonnull String> extraFields = Collections.emptyMap();

kaikreuzer
5 days ago
If you want to introduce null annotations with the new fields/method, you should make the whole class consistently use null annotations - and this means you should annotate it with @NonNullByDefault and then rather add @nullable annotations at the appropriate places.

So I add the @NonNullByDefault to the class, and add @nullable on old field to keep compatibility (I was thinking).
Let me look at compilation error so I try to find out what's wrong with that.

Laurent

@holgerfriedrich
Copy link
Copy Markdown
Member

Hi Laurent, this happens from time to time and there is nothing to be sorry for.
Basically the change from no annotations to annotations is now making the binding code aware that there might be a missing null check.
Then it is probably good to fix that on add-ons side (and for consistency change the parameter of setTokenType to Nullable).

I worked in on an PR to remove all Null warnings in the past which basically changed AccessTokenResponse in a similar way you did. There is a draft PR for add-ons which could already contain the required changes. The first hit searching getAccessToken already shows what I had done to fix automower (currently the build fails there). https://github.com/openhab/openhab-addons/pull/18915/changes

@lo92fr
Copy link
Copy Markdown
Contributor Author

lo92fr commented Mar 11, 2026

he @NonNullByDefault to the class, and add @nullable on old field to keep compatibility (I was thinking).
Let me look at compilation error so I try to find out what's wrong with that.

Ok, I effectively don't see the side effect on other addons, that seems massive.
I think the better for now would be to create another PR to remove the @nullable change on AccessTokenResponse.
And perhaps come back later to fix more deeply the class.
Like this, it will enable a quick fix to make thing compile again.

Laurent.

@lo92fr
Copy link
Copy Markdown
Contributor Author

lo92fr commented Mar 11, 2026

We are just cross-posting at the same time !
Yes I was also looking at automower.

Yes I'm agree would be better to add the annotation.
But don't know how many time to fix all the addons.

So let me know, perhaps more simple to make it a 2 pass process:

  • First a quick PR to revert the nullable change, that could be ready in 1 hour.
  • Second a more deep PR to get back the @NonNullByDefault, and fix all addons.

Let me know !

@holgerfriedrich
Copy link
Copy Markdown
Member

I think it is not too much to fix on add-ons side. I just searched the PR I mentioned above. Automower is the biggest change. A few more bindings need a new null check / exception blocks.

On core side, the setters in AccessTokenResponse which have corresponding getters with Nullable return value, should have Nullable parameters. Could you pls. create this first, then I can merge and start a CI build.

I can care for the add-ons side in the meantime.

@lo92fr
Copy link
Copy Markdown
Contributor Author

lo92fr commented Mar 11, 2026

ok, I prepare the change getters/setters

@lo92fr
Copy link
Copy Markdown
Contributor Author

lo92fr commented Mar 11, 2026

ok, I prepare the change getters/setters

@holgerfriedrich,

The PR for AccessTokenResponse is there:
#5417

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement An enhancement or new feature of the Core

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants