This post looks at an alternative way of implementing a native app authentication and authorization. At present, a web browser is used to implement authentication of native applications when using OAuth and OpenID Connect. The alternative approach implemented in the post is based on the OAuth 2.0 for First-Party Applications draft and adapted to be focused on the device/application. The aim is to focus on having an authenticated device and onboard to user to the device without gaps in the secure channels. Forcing a phishing resistant authentication can be a native implementation on the device and is responsibility of the business.

A working and experimental PoC can be found here:

Code: https://github.com/damienbod/OAuthClientAssertionsPerInstance

The example uses Duende IdentityServer to implement the flow and a console application is used to implement the native application.

Description

Principal idea: The application on the device could be authenticated first and the user can be attached to the application.

The device would use private/public keys and the server would create and attach an “auth_session” for the “public_key”. An adaption to the client assertion would be required. The OAuth client credentials flow using client assertions to request the token can be used from this point onwards. All access tokens would include the auth_session and further authorization can be implemented using this.

Once the device can request an access token, the user properties can be attached to this secure instance as required. The business application can decide the level of user authorization after this.

Advantages (compared to actual draft)

• Application/Device is authenticated first and is unique.
• Application/Device binding of the auth_session value ensures that the context referenced by the auth_session cannot be stolen and reused by another device.
• User onboarding can be implemented in an application specific way and use an existing OAuth standard to onboard. No security changes are required for the endpoint. (OAuth client credentials token with auth_session claim in token.)
• The device is responsible for user onboarding and the results can be attached to the server device session as required in the business.
• No refresh tokens are required, but can be used.
• The user recovery process can be implemented in a business specific way. Not part of the security specifications.

Disadvantages

• Client assertion needs to be adapted on existing implementations.
• auth_session included in the application access token must be attached to the client assertion request. No gaps.
• Initial session setup endpoint is unsecure and open to DDoS attacks

The flow could look like this:

Figure: First-Party Client Authorization Device Request

• (A) The first-party client starts application for the first time and creates an asymmetric private, public key pair. The client initiates the authorization request by making a POST request to the Device Registration Endpoint using the public key.
• (B) The Authorization Server determines whether the information provided to the Device Registration Endpoint is sufficient. The server creates an ‘auth_session’ for the public key and returns the ‘auth_session’ in the response.
• (C) The Device requests an access token with a client assertion and OAuth client credentials created using the private key. The ‘auth_session’ is added to the client assertion using the ‘device_auth_session’ claim. The public key attached to the auth_session is used to validate the client assertion. Optional, DPoP is used to request the token. DPoP does not use the same private, public key pair.
• (D) The Authorization Server returns an access token from the Token Endpoint. The ‘auth_session’ is returned in the access token.
• (E) The Authorization Challenge Endpoint is used to attach user authentication properties to the device and the auth_session. The Authorization Server authorises the access token using standard OAuth requirements, including DPoP. The auth_session claim is used to authorize specifics for the user.
• (F) ..
• (G) repeat for n-user properties
• (H) ..

Flow details

The flow details can be found here:

https://github.com/damienbod/OAuthClientAssertionsPerInstance/blob/main/OAuth_first_party_adapted_draft.md

Links

https://docs.duendesoftware.com/identityserver/v7/tokens/authentication/jwt/

https://docs.duendesoftware.com/identityserver/v7/reference/validators/custom_token_request_validator/

https://docs.duendesoftware.com/identityserver/v7/tokens/authentication/jwt/

https://docs.duendesoftware.com/foss/accesstokenmanagement/advanced/client_assertions/

https://www.scottbrady.io/oauth/removing-shared-secrets-for-oauth-client-authentication

Specs

https://www.rfc-editor.org/rfc/rfc7636

https://datatracker.ietf.org/doc/draft-ietf-oauth-first-party-apps

https://github.com/oauth-wg/oauth-first-party-apps

https://github.com/oauth-wg/oauth-first-party-apps/blob/main/draft-ietf-oauth-first-party-apps.md

https://datatracker.ietf.org/doc/html/rfc9449