menu arrow_back close search On Github

Client security measures

  1. Home
  2. Authorization & authentication
  3. Client security measures

In this document, we present a list of important security measures that need to be taken into account when implementing clients that integrate towards the authentication and authorization APIs for CONNECT ID.

Store secrets securely

Encrypt all communication to and from clients

Encryption could be done e.g. using TLS/SSL (HTTPS). CONNECT only allows use of TLS/SSL (HTTPS) for requests towards its authorization server and resource servers. Service providers need to make sure that all other communication to and from the clients, e.g. with service-specific resource servers, is encrypted appropriately.

Protect client callback endpoint against CSRF attacks

Clients must protect the redirect URI client callback endpoint against cross-site request forgery (CSRF) attacks, according to section 10.12 in the OAuth specification (RFC 6749). The recommended way to avoid CSRF attacks is to supply a cryptographically random value in the state parameter for the authorization request and verify it for the response in the client callback endpoint, ref client sample code. Please see section 10.12 in the OAuth specification (RFC 6749) and section in the OAuth 2.0 Threat Model and Security Considerations specification (RFC 6819) for details. Note that no confidential data should be passed in the state parameter.

Validate access token for all access to protected resources

Clients must validate the access token for all access to protected resources, including its own service-specific protected resources. As mentioned in the access token validation documentation, this should be done according to section 7 in the OAuth specification (RFC 6749) and the OAuth bearer token usage specification (RFC 6750).

Validate ID token if the openid scope value is used

If the client is requesting an ID token by asking for the openid scope value, the returned ID token must be validated. As mentioned in the ID token validation documentation, this should be done according to the OpenID Connect Core spec, section

Recommendation: Use an external browser for authorization request for native apps

Native apps typically have a number of different choices for what kind of browser to use for redirects to the /authorize endpoint. Typical choices are:

  1. An external browser (the system browser).
  2. A secure embedded browser that provides sandboxed integration with an external browser. Examples: Safari View Controller on iOS and Chrome Custom Tabs on Android.
  3. A less secure embedded browser. Example: WebView.

For native apps on platforms that we do not provide an SDK for, we recommend using an external browser (i.e. not an embedded browser). One main reason is that using an embedded browser defeats the purpose of OAuth, which is that the end user should only supply their credentials directly to the authorization server, and not to or via the client.

Despite the important security advantages of using an external browser, it is relatively common to use embedded browsers for third party login in apps. Apple does even require that a user should be able to log in without opening an external browser, in order for an app to be accepted for the App Store. Therefore, an embedded browser has to be used for iOS apps and may be used for apps on other platforms as well. If the SDK is not used for an iOS app, we recommend using Safari View Controller, available on iOS 9 and onward. If neither the SDK nor an external browser is used for an Android app, we recommend using Chrome Custom Tabs, available with Chrome 45 on Android 4.1 and onward.

We discourage using WebViews for the following reasons:

Edit this page