IBM Verify

IBM Verify

Join this online user group to communicate across Security product users and IBM experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only
  • 1.  OAuth2.0 authorize equest respone location with #

    Posted Thu April 23, 2020 06:24 AM
    Edited by Piyush Agrawal Thu April 23, 2020 06:25 AM

    Hello,

    Very basic question but when we are trying oauth with code flow then response from /mga/sps/oauth/oauth20/authorize on redirect_uri=https://www.testportal.no/app/mobile-demo/oauth/oauth2Client.jsp

    Response header location looks like

    https://www.testportal.no/app/mobile-demo/oauth/oauth2Client.jsp#access_token

    is it possible to change "#" and replace it with "?"



    ------------------------------
    Piyush Agrawal
    ------------------------------


  • 2.  RE: OAuth2.0 authorize equest respone location with #

    Posted Thu April 23, 2020 08:17 AM
    Hello Piyush,

    If you are getting back #<access token> from your  ​request to /authorize then you have triggered an Implicit flow and not an Authorization Code flow.  To trigger an Authorization Code flow, make sure that your request includes response_type=code.

    Jon. 


    ------------------------------
    Jon Harry
    Consulting IT Security Specialist
    IBM
    ------------------------------



  • 3.  RE: OAuth2.0 authorize equest respone location with #

    Posted Thu April 23, 2020 04:38 PM
    Edited by Piyush Agrawal Fri April 24, 2020 12:00 AM

    Thank you for Reply Jon.

    Bad example actually I am getting response as 

    https://www.testportal.no/app/mobile-demo/oauth/oauth2Client.jsp#state=3zWrQCYvPJDBcVsc56IW&code=jjUbDvBwGysnCjDbYrFhevlj0hK5hH&id_token=eyJraWQiOiJo....

    # is present in Implicit and hibrid flow but not in Authorization Code Flow.

    Here is an example of Auth Request with response_type= code id_token

    https://authserver.com/mga/sps/oauth/oauth20/authorize?
    client_id=testclient
    &scope=openid
    &response_type=code%20id_token
    &state=3zWrQCYvPJDBcVsc56IW
    &code_challenge=94bbea8e27c8b382b6bef307xfdfsdfadfdsfsd
    &code_challenge_method=sha256&nonce=blah
    &redirect_uri=https://www.testportal.no/app/mobile-demo/oauth/oauth2Client.jsp

    ​Regards,
    Piyush

    ------------------------------
    Piyush Agrawal
    ------------------------------



  • 4.  RE: OAuth2.0 authorize equest respone location with #

    Posted Fri April 24, 2020 02:18 AM
    Hi Piyush,

    This is intended behavior, see the OpenID Connect specification here:
    "When using the Implicit Flow, all response parameters are added to the fragment component of the Redirection URI, as specified in OAuth 2.0 Multiple Response Type Encoding Practices [OAuth.Responses], unless a different Response Mode was specified."

    You could try adding the following query parameter to the request:
    https://authserver.com/mga/sps/oauth/oauth20/authorize?
      ...
      response_mode=query​

    But I haven't tested whether that works. (it can have two values: query and fragment).

    Kind regards,

    ------------------------------
    Dries Eestermans
    IS4U
    ------------------------------



  • 5.  RE: OAuth2.0 authorize equest respone location with #

    Posted Fri April 24, 2020 07:38 AM
    Hello,

    I'm not sure that we support response_mode=query.  However, for OIDC we *do* support response_mode=form post.
    This will cause response from /authorize to be a form post.   It may even be possible to customize the content of the returned page (in template files) if you want to make it easier to consume in client code.

    Jon.

    ------------------------------
    Jon Harry
    Consulting IT Security Specialist
    IBM
    ------------------------------



  • 6.  RE: OAuth2.0 authorize equest respone location with #

    Posted Tue April 28, 2020 11:45 AM
    Thank you for answer..  it is as per specifications..
    on metadata file /mga/sps/oauth/oauth20/metadata/<def_name> we can see supported response Modes
     response_modes_supported":["fragment","form_post"]


    I didn't do any changes in configuration but advice client developer to handle frament correctly on javascript application.. Problem is solved now.

    ------------------------------
    Piyush Agrawal
    ------------------------------