Visual Builder

Get Involved. Join the Conversation.

Topic

    Mohana Gopal Selvam
    Resource Owner OAuth2.0 - Bearer Token ConfigurationAnswered
    Topic posted July 29, 2019 by Mohana Gopal SelvamSilver Crown: 22,500+ Points, tagged REST 
    38 Views, 19 Comments
    Title:
    Resource Owner OAuth2.0 - Bearer Token Configuration
    Content:

    Hi,

    We have Token API which doesnt have Client Id & Client Secret, it has only user name & password. I tried to create connection using 'Resource Owner OAuth2.0' authorization, but got the below error when I test my API. Please find the configuration screenshot. 

    {
        "type": "HTTP://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.1",
        "status": 400,
        "title": "Bad Request",
        "detail": "{\"type\":\"abcs://proxy_problem/oauth/client\",\"title\":\"Missing OAuth Value\",\"detail\":\"Missing client_id and client_secret for third party server\",\"status\":400}"
    }

    How to achieve this in VBCS. Please note I am using OIC - VBCS.

    Thanks,

    Mohan

    Image:

    Best Comment

    Aparna Gaonkar

    VB relies on IDCS for its authentication flows, for the VB application itself to communicate with other services like OIC, it itself is assigned a client id and secret.   The client id and secret is actually mandatory for VB, however if you dont provide it on the screen, it internally defaults to the client id and secret of the VB application (which is useful in some scenarios like this one - https://docs.oracle.com/en/cloud/paas/app-builder-cloud/visual-builder-developer/connect-content-and-experience-cloud-using-identity-propagation.html) .  In conclusion it means there is a client id and a secret in all the client creds and resource owner password flows.  We treat the VB application as a confidential client and according to the OAuth RFC recommendations use a client id and a client secret always.  

    Imagine multiple clients (or applications) calling this API, each one should be assigned a unique client id.  Tomorrow if you want to mark one client as malicious, you could do this without affecting the other clients.  Not having a client id actually kind of defeats the purpose of OAuth, the API might as well use Basic Authentication with username and password because it is not offering any advantage.

    Comment

     

    • Aparna Gaonkar

      In OAuth 2.0 specification (https://tools.ietf.org/html/rfc6749), you need to have a way to identify your client to the OAuth server.  Are you expecting a Client credentials grant here instead of Resource Owner Password?  In which case you can try to give the username as client id and password as client secret with the Client Credentials grant type.

    • Mohana Gopal Selvam

      Hi Aparna,

      Got the below error.

      {
          "type": "HTTP://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.1",
          "status": 401,
          "title": "Unauthorized",
          "detail": "{\"type\":\"abcs://proxy_problem/oauth/auth_token_error\",\"title\":\"OAuth token resource returned an error\",\"detail\":\"OAuth token resource responded with status code unauthorized_client and body:\\n\\n{1}\",\"status\":401,\"o:vbcs-token-response\":{\"error\":\"unauthorized_client\"}}"
      }

    • Mohana Gopal Selvam

      Hi Aparna,

      Grant_type is Password. Find the Postman screenshot.

      Thanks,

      Mohan

    • Mohana Gopal Selvam

      Find the SendSMS screenshot.

       

      • Aparna Gaonkar

        Does the service /token accept any Authorization header?  According to the OAuth 2.0 specs it should.  I can see from screenshot it accepts the following: grant_type, username, password.  Apart from this it should ideally also have some Authorization header to authenticate itself to the OAuth Server.

    • Mohana Gopal Selvam

      Hi Aparna,

      There is no other authorization to get the token except grant_type, username & password. This what we get it from the customer.

      Thanks,

      Mohan

      • Aparna Gaonkar

        Then Mohan, this is a non-standard OAuth practice - We follow the OAuth recommendations given in https://tools.ietf.org/html/rfc6749 - check the example below given in the RFC:

        POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=password&username=johndoe&password=A3ddj3w

        For a workaround, Could you check with the customer if:
        1/ There is another grant type like Client Credentials for the API 
        2/ If the username/password can be send in headers rather than url encoded format
    • Mohana Gopal Selvam

      Hi Aparna,

      1/ There is another grant type like Client Credentials for the API 
                          I have another grant type (Client Credentials), but it is not working
      2/ If the username/password can be send in headers rather than url encoded format
                         I have tried to pass user name & password value in parameter, but I got error message as 'Invalid Grant Type' in Postman.
       
       
      Thanks,
      Mohan
    • Mohana Gopal Selvam

      Hi Aparna,

      I tried to say, I have already tried Client Credentials as one of the Authorization in VBCS. But it is error out, I shared the details in the thread.

      It is working in Postman, even I can able to create connection in OIC using this APIs.

      Thanks,

      Mohan

    • Mohana Gopal Selvam

      Find the OIC test connection screenshot

    • Mohana Gopal Selvam

      Hi Aparna,

      Find my Access Token Request. I have used grant_type = 'password'

      -X POST https://xx.xx.xx.xx/smsapisecure/token -H 'Content-Type: application/x-www-form-urlencoded' -d 'username=SMSSIT&password=SMS$1&grant_type=password'

      Thanks,

      Mohan

      • Aparna Gaonkar

        Ok Mohan, that is not client credentials grant type, but reource owner password.  If you have a request that works with "grant_type=client_credentials" , that would be Client Credentials.  If you dont have an alternate authentication for this API, I would suggest you can use the OIC Rest Adapter to connect to the API and then consume the OIC API within VBCS.

    • Mohana Gopal Selvam

      Thanks for your reply.

      What would be the reason ? Resource Owner 2.0 - VBCS requires only user name & passsword in UI. But it expects Client Id & secret as per the error. Then it should be the mandatory field in the UI.

      Note: I havent read the document https://tools.ietf.org/html/rfc6749  :-) 

      Thanks,

      Mohan

      • Aparna Gaonkar

        VB relies on IDCS for its authentication flows, for the VB application itself to communicate with other services like OIC, it itself is assigned a client id and secret.   The client id and secret is actually mandatory for VB, however if you dont provide it on the screen, it internally defaults to the client id and secret of the VB application (which is useful in some scenarios like this one - https://docs.oracle.com/en/cloud/paas/app-builder-cloud/visual-builder-developer/connect-content-and-experience-cloud-using-identity-propagation.html) .  In conclusion it means there is a client id and a secret in all the client creds and resource owner password flows.  We treat the VB application as a confidential client and according to the OAuth RFC recommendations use a client id and a client secret always.  

        Imagine multiple clients (or applications) calling this API, each one should be assigned a unique client id.  Tomorrow if you want to mark one client as malicious, you could do this without affecting the other clients.  Not having a client id actually kind of defeats the purpose of OAuth, the API might as well use Basic Authentication with username and password because it is not offering any advantage.

    • Mohana Gopal Selvam

      Thanks Aparna.