Quick Login (Implicit Grant)

Updated March 13th 2017

The OpenID Connect specification includes an authentication flow that allows for user-agent (e.g. browser) only functionality. This meets two objectives. Firstly, it means you do not have to store a client secret (because it is not possible to store this securely in the HTML page) and secondly, this therefore removes the need or ability to make the first web service call, which would normally turn the grant code into an access token. This call would normally require the secret in order to authenticate the client with the auth server.

The point here is to firstly allow things like Javascript-only authentication (not involving the client's server) and secondly to make auth quicker.

The summary of the implications for your implementations are:

  1. Your redirect uri MUST use SSL/TLS, if it does not, the login handshake will fail.
  2. You should take special care that the redirect URI does not allow reflection or redirection attacks
  3. The user information returned will be less than it would if the full flow was used i.e. it will not include anything that has security implications.

The technical details for these implications are:

  1. The authentication is quicker because there are 2 less web service calls. This may or may not be noticeable depending on network performance.
  2. The client is never securely authenticated with the server since the secret is no longer in play. Therefore anyone could impersonate your client during the first part of the handshake and without additional protections, potentially intercept the reply/id token to harvest data. It is essential that you use a secure return URI and not one that is prone to reflection attacks or unvalidated redirection to an attackers site. Your redirect uri is vulnerable to reflection if it allows any additional input in the uri (that an attacker might add) to be rendered onto the page or executed in some way - an attacker could force your page to display or execute some script which could pass the access token onto them. Your redirect uri is vulnerable to unvalidated redirection if it does not limit the URLs that can be redirected to - so an attacker tricks the redirect uri into redirecting onto an attackers site, presumably also passing the access token with it.
  3. The id token is transmitted directly in the URI (encrypted) when the auth server redirects from the initial user login. For this reason, clients requiring implicit grant functionality MUST use SSL/TLS in their redirect uri to protect this id token. You will need to register this https redirect URI with your developer account but at this stage, the PixelPin system will not ask you to specify implicit grant and will not prevent you typing an http URI. What would happen is that if implicit grant is requested, passing an HTTP redirect URI will produce an error.
  4. There is still a reasonable chance that an access token is obtained from a hacked site (since hacking the client is easier than hacking a server), therefore the data returned from PixelPin for a user using the implicit grant will not include anything security related, such as the "keyid" encryption key. The same risk is present since the user data is being sent directly to the user-agent rather than being secured on a server. In other words, this data could be obtained directly from a compromised application, which is another reason why the returned data will be limited. Since PixelPin does not currently hold (or plan to hold) large amounts of customer data, this risk is fairly limited.

The id token itself is encrypted and signed but it is up to the client to verify this token, potentially by calling https://login.pixelpin.co.uk/connect/identityTokenValidation.