Oauth2: expires_in and refresh_token should be optional

[jasollien]

From oauth2 docs (https://tools.ietf.org/html/rfc6749#section-5.1)

expires_in is RECOMMENDED and
refresh_token is OPTIONAL.

I am however not sure if expires_in should be optional or recommended.

[GeorgDangl]

I guess there's no harm in allowing tokens to not expire. That would make two different token responses.

Variant 1 - Expires with a certain lifetime and must be refreshed by the client

{
    "access_token": "Zjk1YjYyNDQtOTgwMy0xMWU0LWIxMDAtMTIzYjkzZjc1Y2Jh",
    "token_type": "bearer",
    "expires_in": "3600",
    "refresh_token": "MTRiMjkzZTYtOTgwNC0xMWU0LWIxMDAtMTIzYjkzZjc1Y2Jh"
}

Variant 2 - Never expires (but can still be revoked!)

{
    "access_token": "Zjk1YjYyNDQtOTgwMy0xMWU0LWIxMDAtMTIzYjkzZjc1Y2Jh",
    "token_type": "bearer"
}

I guess Variant 1 has the benefit of making it harder to share the keys, so it would probably support a desired behaviour of having specific tokens associated to specific device/app/user combinations.
Therefore we should just stick with the way it's currently done (requiring the expires_in property).

Do you see any benefits in making the expires_in optional?

[jasollien]

The benefit is quite egoistic.
It allows servers without support for timeout and refreshToken (still according to the oauth2 specifiacation) to support BCF.

bimsync does unfortunately not have support for expires_in and refresh_token at the moment.

I hope, making them optional, will make it easier for new servers on the market.

[KevLoh]

@GeorgDangl

Do you see any benefits in making the expires_in optional?

The benefit is to be in line with oauth2 specification as Jon Anders stated.

BCF should not specify oauth2 again (and then differently to the official one).

A client gets problems, if she relys on BCF's oauth2 specification, but a server on the official one.

[GeorgDangl]

See #124