Add OAuth Refresh token when openid scope is used

[DavidKarlas]

Description

OSM access_token don't have expiry but id_token which is generated when openid scope is enabled has expiry of 2 minutes. Making id_token to also never expiry seems to me more problematic than no expiry for access_token because id_token can not be revoked, hence it is important to have short expiry. But with short expiry it makes id_token not very useful and it would complicate authentication against 3rd party services. Instead I think it is better to enable refresh token on OSM when openid scope is enabled for app which allows apps to refresh id_token by calling /oauth/token using refresh token. This way app can refresh id_token at any time and send it to 3rd party service which can authenticate user.

How has this been tested?

Added unit tests, and manually on my machine, also verified that calling /oauth/token with refresh token works and produces fresh id_token.

More details

My main goal on how to use this is following. Mobile app such as EveryDoor, StreetComplete... Can add openid to their OAuth Application scopes. That will result in getting id_token property in JSON of osm.org/oauth/token that can be passed to Panoramax as Authorization Bearer jwt_token_that_osm.org/oauth/token_returned_in_id_token_field when uploading photos. This will allow Panoramax API to use https://www.openstreetmap.org/oauth2/discovery/keys which has public key stored that can be used to verify the id_token and authenticate user. So from user perspective no additional logins or anything else needs to be done against Panoramax service. Another nice thing about sending OpenConnect ID token is that even if Panoramax service is compromised, this token is only useful to confirm this user did action, it does not give Panoramax any authorization to do anything against osm.org API.
With this PR, mobile app will be able to fetch fresh id_token at any time and send it to Panoramax service which can authenticate user as long as whole operation takes less than 2 minutes which should be plenty.
Without this PR there would be 3 options IMO:

• Panoramax would need to ignore expiry
• User would need to do whole OAuth dance to get fresh id_token
• Mobile app would need to perform login into Panoramax immediately after user does OAuth dance on osm.org to get access_token from Panoramax, which would complicate work for Mobile app and Panoramax, since both would need to maintain tokens between them. Biggest problem with this is unnecessary connections to Panoramax, just in case user decides to upload something in future, which might never happen.

[mmd-osm]

I'm wondering why you want to send id_tokens to a resource server in the first place. That's not really their intended use: https://oauth.net/id-tokens-vs-access-tokens/

[DavidKarlas]

I did some more investigation into this, and I agree using id_token as way to login into 3rd party service is not very standardized way of doing things, here is rare example of that being done: https://kubernetes.io/docs/reference/access-authn-authz/authentication/#openid-connect-tokens

While investigating 3rd option of exchanging id_token for access_token on 3rd party service seems most common way of doing things, which can be done today without adding refresh_token, only downside will be that Mobile app needs to acquire access_token as soon as user logs in and not later when actually needed.