OpenIDConnect prompt parameter in Wso2 Identity Server

From this blog post we will see how Wso2 IS supports for prompt parameter to be used in OpenIDConnect authentication request by using the playground sample.

The Prompt parameter

According to the OpenIDConnect specification, by using prompt parameter we can force the authorization server to do specific tasks. Wso2 Identity Server 5.1.0 (which will be released in few weeks) supports three values to be used with prompt parameter.

prompt=none  

If an end user is not already authenticated  or if there is not pre-configured consent(though there is an already authenticated user) the Identity Server will return an error page and if there is an already authenticated user and pre-configured consent the Identity Server will provide the authorization code.

We can send the authentication request with prompt parameter to Identity server by using playground sample as follows.

If there is not already authenticated end user you will get an error from Identity Server as below.
Though you have an authenticated user but not pre-configured consent (if you have not approve always or set skip consent from file) then also you will get an error as access-denied.

If you authenticate the user in the same session and set the consent as approve the user will get the authorization code. And if you authenticate the user in the same session and if you have set the consent as approved always in a previous session then also you will get the authorization code as below.


prompt=login

When we are using prompt=login with authentication request then the IS server prompt the end user for re authentication. If it does not have pre-configured consent then it will ask for consent too.

prompt=consent

This is kind of forcefully sending the request to consent page. Though there is a pre-configured consent if the user request for prompt=consent in authentication request then IS server will prompt the consent page.






Comments

Post a Comment

Popular posts from this blog

Applying CORS Filter to wso2 Identity Server

When we are invoking an endpoint in oauth2 war from a javascript of a web app which is located in a different domain than identity server domain we are getting "No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://XXXXXXX is therefore not allowed access." The issue is occurring as the script on your page is running from a specifc domain and would try to request the resource via an XmlHttpRequest or XDomainRequst from a different domain as this is a cross -origin request. In order to get rid of this we need to enable this by sending below header using a custom filter.  Access-Control-Allow-Origin: http: //example.com   (Here  http://example.com is the domain name of where page with that script is hosted) Invoking UserInfo endpoint of wso2 Identity Server from JavaScript We have two possible solutions to apply the CORS header.  1. Customizing OpenIDConnectUserEndpoint.java as below and replacing the oauth
Read more

JWKS endpoint of wso2 IS

What is JWKS endpoint? The JSON Web Key Set (JWKS) endpoint is a read-only endpoint. This url returns the Identity Server's public key set in Json web key set format. This contains the signing key(s) the RP uses to validate signatures from the Identity Server. This endpoint is defined loosely by the OpenID Connect Discovery specification . Try JWKS endpoint with Identity Server The endpoint url for the super tenant: https://localhost:9443/oauth2/jwks The jwks for the super tenant will be as follows: { "keys" : [ { "alg" : "RS256" , "kty" : "RSA" , "use" : "sig" , "n" : " AJSn-hXW9Zzz9ORBKIC9Oi6wzM4zhqwHaKW2vZAqjOeLlpUW7zXwyk4tkivwsydPNaWUm-9oDlEAB2lsQJv7jwWNsF7SGx5R03kenC-cf8Nbxlxwa-Tncjo6uruEsK_Vke244KiSCHP8BOuHI-r5CS0x9edFLgesoYlPPFoJxTs5 " , "e" : "AQAB" , "kid" : " d0ec514a32b6f88c0abd12a2840699bdd3deba9d "
Read more

DCR VS DCRM with WSO2 Identity server

Image
What is DCR (Dynamic Client Registration) Dynamic Client registration is a protocol which allows OAuth clients to register applications in an authorization server. Before this mechanism which is introduced from the spec [1] the client registration happened manually. With this implementation the client registration could be done in two ways.  - A client can be registered dynamically with the authorization server itself  - A programmer can register a client programmatically. Following is the protocol flow of DCR 1. A client sends a registration request with as follows. This should be a post request. 2. Server sends information response with 201 created. Request : POST   https://localhost:9443/api/identity/oauth2/dcr/v1.0/register HTTP/1.1 Authorization : Basic   YWRtaW46YWRtaW4= Content-Type :   application/json Content -Length :   114 Host: localhost :9443 {    "redirect_uris" : [      " http://localhost"    ],   
Read more