OpenID Connect Implicit flow with WSO2 Identity Server.
OpenID Connect presents 3 flows for authentication. These flows dictate how authentication is handled by the OpenID Connect Provider, including what can be sent to client application and how.
The main 3 flows are,
- Authorization Code flow
- Implicit flow
- Hybrid flow
Lets see how implicit flow works in OpenID Connect. Now playground app also supports implicit flow.
When do we need to use implict flow?
The main difference between authorization code flow and implicit flow is,
- In authorization code flow, ID token is sent in back channel way when the client (Relying party) sends its client password in back-channel.
- But in implicit flow, Since the implicit flow is used in single page applications and in the clients which are implemented in browser , the ID token is sent in front-channel. In this flow, the client does not need to send its password to the OP.
Implicit flow steps
- Client prepares an Authentication Request containing the desired request parameters.
- Client sends the request to the Authorization Server.
- Authorization Server Authenticates the End-User.
- Authorization Server obtains End-User Consent/Authorization.
- Authorization Server sends the End-User back to the Client with an ID Token and, if requested, an Access Token.
- Client validates the ID token and retrieves the End-User’s Subject Identifier.
for a implicit grant type, the client should process all the steps.
Authentication Request in implicit flow
- Response_type : This indicates what value should be returned from the endpoint. So in OIDC implicit flow,
response_type= id_token orreponse_type=id_token token
if response_type= id_token, then authorization end point should return only id token.
if response_type= id_token token, then the authorization endpoint should return access token and id_token.
- redirect_uri : it is the uri to which the response should be sent. This should match with pre-registered uri.
- nonce :String value used to associate a Client session with an ID Token, and to mitigate replay attacks. nonce value should be sent by the client during implicit flow. Then the value is passed through unmodified from the Authentication Request to ID token
How to play with WSO2 IS server?
response_type= id_token
- If you want to play with OpenID Connect implicit flow in IS server (since playground app does not support OIDC implict flow yet), send a HTTP GET request to the server.
https://localhost:9443/oauth2/authorize?response_type=id_token&client_id=
3T9l2uUf8AzNOfmGS9lPEIsdrR8a&nonce=CqsU9wZlQIYGUB86&
redirect_uri=http://localhost:8080/playground3/oauth2client&scope=openid2. After giving user credentials and approve the consent page, you can get id token in the response.
http://localhost:8080/playground2/oauth2client#id_token=eyJ4NXQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJraWQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJhZG1pbiIsImF1ZCI6WyIzVDlsMnVVZjhBek5PZm1HUzlsUEVJc2RyUjhhIl0sImF6cCI6IjNUOWwydVVmOEF6Tk9mbUdTOWxQRUlzZHJSOGEiLCJhdXRoX3RpbWUiOjE1MDcwMDk0MDQsImlzcyI6Imh0dHBzOlwvXC9sb2NhbGhvc3Q6OTQ0M1wvb2F1dGgyXC90b2tlbiIsImV4cCI6MTUwNzAxMzAwNSwibm9uY2UiOiJDcXNVOXdabFFJWUdVQjg2IiwiaWF0IjoxNTA3MDA5NDA1fQ.ivgnkuW-EFT7m55Mr1pyit1yALwVxrHjVqmgSley1lUhZNAlJMxefs6kjSbGStQg-mqEv0VQ7NJkZu0w1kYYD_76-KkjI1skP1zEqSXMhTyE8UtQ-CpR1w8bnTU7D50v-537z8vTf7PnTTA-wxpTuoYmv4ya2z0Rv-gFTM4KPdxsc7j6yFuQcfWg5SyP9lYpJdt-s-Ow9FY1rlUVvNbtF1u2Fruc1kj9jkjSbvFgSONRhizRH6P_25v0LpgNZrOpiLZF92CtkCBbAGQChWACN6RWDpy5Fj2JuQMNcCvkxlvOVcx-7biH16qVnY9UFs4DxZo2cGzyWbXuH8sDTkzQBg&session_state=4e39a6e2542dfb886060395090ab295c169bd4fc0c4e60ad71330c906113be97.PHZtMmcmY-4tvSyOQGYEPQ
The value of the nonce Claim MUST be checked to verify that it is the same value as the one that was sent in the Authentication Request. By comparing this, we can find and mitigate the replay attacks.
response_type= id_token token
- If you want, access token and id token in the response, the request should be as,
https://localhost:9443/oauth2/authorize?response_type=id_token token&client_id=
3T9l2uUf8AzNOfmGS9lPEIsdrR8a&nonce=CqsU9wZlQIYGUB86&
redirect_uri=http://localhost:8080/playground3/oauth2client&scope=openid2. Then the response will be as
http://localhost:8080/playground2/oauth2client#access_token=79bb62dc-132d-37c7-a8d8-d0a495129cec&id_token=eyJ4NXQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJraWQiOiJOVEF4Wm1NeE5ETXlaRGczTVRVMVpHTTBNekV6T0RKaFpXSTRORE5sWkRVMU9HRmtOakZpTVEiLCJhbGciOiJSUzI1NiJ9.eyJhdF9oYXNoIjoiS2hBT2h1cE04QnZaT0pXd19mNndkQSIsInN1YiI6ImFkbWluIiwiYXVkIjpbIjNUOWwydVVmOEF6Tk9mbUdTOWxQRUlzZHJSOGEiXSwiYXpwIjoiM1Q5bDJ1VWY4QXpOT2ZtR1M5bFBFSXNkclI4YSIsImF1dGhfdGltZSI6MTUwNzAwOTM2NiwiaXNzIjoiaHR0cHM6XC9cL2xvY2FsaG9zdDo5NDQzXC9vYXV0aDJcL3Rva2VuIiwiZXhwIjoxNTA3MDEyOTY4LCJub25jZSI6IkNxc1U5d1psUUlZR1VCODYiLCJpYXQiOjE1MDcwMDkzNjh9.dnEyk37viVBeXP6J68bLMuHoszhU1_-ffk3H1XVqMKA_D6tAVhoZGM8rn0EH5lTf126-eQLhV7CaK3pGR3mJOp2a1HS06HFHfaIpG2uGRxLHq6qW9i_y4GRZb3q40ZuXZaInwJ1__FLUy96dyme07V2LgkIRJWej-6-OTLeBkeHiiGYCSuuR-HfemCABTwTqRYGRV1rnCepnLKk8o5JCVunZZ4MzxH1hmvZLWhp5G0ITxlOn55tUGTsD2jemmZOdMrVO946p09E73kAIgJpbQkEovY93Mw6bpgLr4FVT0vg6e4SEIUbhUb-W17a6DOSrKzgYDADovM4aieQEF6Kbnw&token_type=Bearer&expires_in=3600&session_state=93c9deb60f36a16edf42ae767bfcef285aed42ce04e978ccb82193f2d4cbffb2.vhBolwXjbdKT2ELyfY__pw
How response parameters should be handled?
Look at the response.
Here response parameters should be sent as URI fragment. Since response parameters are returned in the Redirection URI fragment value, the Client needs to have the User Agent parse the fragment encoded values and pass them to on to the Client’s processing logic for consumption.
The implicit flow requests tokens without explicit client authentication, instead using the redirect URI to verify the client identity. This flow is not suitable for long lived access tokens. From the client application’s point of view, this is the simplest to implement, as there is only one round trip to the OpenID Connect Provider.
