17 Replies Latest reply on Dec 4, 2014 12:40 PM by craig.mcclanahan

    Using OAuth 2.0 - Seeing blank pages or browser errors for /api/core/v3/oauth2/authorize

    c-check

      In working on the OAuth 2.0 I have yet to have any success. I've tried "https://sandbox.jiveon.com/api/core/v3/oauth2/authorize" with the appropriate "client_id" variable from my OAuth 2.0 add-on that I've uploaded. With the correct "redirect_uri" variable, I'm seeing a browser invalid response error "cannot display page." With any other "redirect_uri" I'm seeing just a blank response.

       

      This is the content of my add-on's meta.json:

       

      {

        "package_version": "1.0",

        "minimum_version": "0000",

        "id": "db564234-741b-11e4-b116-123b93f75cba",

        "uuid": "74d8aee-2db5-4753-a715-a748f2790ceb",

        "type": "client-app",

        "name": "OAuth 2.0 Client",

        "description": "This add-on is to register an OAuth 2.0 Client...",

       

       

        "author" : "Curtis Hiller",

        "author_affiliation" : "Drum",

        "author_email" : "chiller@drumagency.com",

       

       

        "service_url": "<my site's redirect url>",

        "redirect_url": "<my site's redirect url>",

       

       

        "icon_16": "",

        "icon_48": "",

        "icon_128": "",

       

       

        "website_url" : <my site's url>,  

        "info_email" : "chiller@drumagency.com", 

        "status": "available",

        "released_on": "2014-11-24T10:55:28.328-0600" 

      }

       

      These are the questions I have:

       

      • Is there some mistake that I'm making in trying to reach the authorize page?
      • For my add-on for OAuth 2.0, what should the meta.json have for service URL and redirect URL? Should both of them be a full domain plus URI?
      • For the add-on I generated random UUIDs for the add-on ID and UUID (tech partner ID?). Is this an appropriate method?

       

      Thanks,

       

      Curtis

        • Re: Using OAuth 2.0 - Seeing blank pages or browser errors for /api/core/v3/oauth2/authorize

          The correct Url should be <jive-url>/oauth2/authorize not <jive-url>/api/core/v3/oauth2/authorize

          1 person found this helpful
            • Re: Using OAuth 2.0 - Seeing blank pages or browser errors for /api/core/v3/oauth2/authorize
              c-check

              Thanks for your help, Nils Heuer and Murali VP -- I've got the entire flow working at this point using my sandbox add-on. I have a follow-up question which is a little more tailored to what I'm trying to accomplish:

               

              Clearly, if I make a request for a person's info from the REST API using a token obtained in this method, it will be limited to the person who credentialized him-or-herself to Jive to complete the OAuth handshake. Is there some way of knowing which user has provided Jive the credentials? It's not ideal for a user to have to provide their email or username for Jive to my app, then provide it again when they are redirected to Jive.

                • Re: Using OAuth 2.0 - Seeing blank pages or browser errors for /api/core/v3/oauth2/authorize
                  Ryan Rutan

                  You should be able to bundle this into the Oauth state information such that it makes its way round-trip.  If that doesn’t work, you may want to look at all the HTTP headers that are coming your way on these requests.  I don’t remember off the top of my head, which headers are included during the Oauth dance; however, there is a feature in Jive where Jive signs a request…and provides username, id and other user identifiers in the headers for such a use case.  Let me know if any of that helps.

                   

                  RR

                    • Re: Using OAuth 2.0 - Seeing blank pages or browser errors for /api/core/v3/oauth2/authorize
                      c-check

                      Ryan Rutan Sending the username in the state would work to keep track of it, but wouldn't solve the issue of needing to collect that information from the user before they authenticate (effectively causing them to have to type it in twice). I don't see anything in the headers for the token request that, to me, implies which user has made the request, either by ID or by email. It would be ideal, for our purposes, if the headers or the response included this type of information. The issue now is that if such a feature exists I'm not sure how I would invoke it on the token request to get that information in the headers.

                        • Re: Using OAuth 2.0 - Seeing blank pages or browser errors for /api/core/v3/oauth2/authorize
                          Ryan Rutan

                          Curtis, could you confirm where you are initiating the Oauth request and how.  Is it a link on a page?  If so, where in the UI experience?  You should be able to do a signed-fetch to kick off the Oauth dance (assuming I understand where you are launching it).

                           

                          Such as:

                          osapi.http.post({

                          'href' : ‘…',

                          ...

                          'authz' : 'signed’,

                          },…);

                           

                          Hope that helps.

                            • Re: Using OAuth 2.0 - Seeing blank pages or browser errors for /api/core/v3/oauth2/authorize
                              c-check

                              Ryan Rutan The idea is to allow users to access our app if they have valid Jive credentials without needing credentials for our app. So, the plan had been to collect username and ID and validate them via Jive. So the user experience was intended to be that of the user entering their Jive credentials on an initial login screen, and then proceeding to access our app. This is why we tried basic auth and OAuth using resource owner grant first as they are both originated using the end user's credentials (both would not work as we're working with "federated" users).

                               

                              Based on the standard for OAuth token access, I'm not familiar with a way to do a signed-fetch that would bypass the need to put in the credentials again upon being redirected to Jive to authorize. I'm also not familiar with a method that would allow us to send the user to Jive before any credentials are entered, and have the user returned to our app with the username as part of the response/header, negating the need to enter it before or after. Either one of these workflows would enable us to spare the user from having to enter (at least) their username twice--once in our app and then again to grant access with Jive.

                               

                              //cc: Murali VP

                                • Re: Using OAuth 2.0 - Seeing blank pages or browser errors for /api/core/v3/oauth2/authorize
                                  This is why we tried basic auth and OAuth using resource owner grant first as they are both originated using the end user's credentials (both would not work as we're working with "federated" users).

                                  Even if not federated, collecting user's credentials for another service is generally not a good idea anyway mainly for two reasons

                                  1. Security concerns (both from the user and the service provider, Jive in this case)
                                  2. Credentials could change, no way for user to un-give permissions, user status could change, etc.

                                   

                                  I'm not familiar with a way to do a signed-fetch that would bypass the need to put in the credentialsagain upon being redirected to Jive to authorize.

                                  Signed fetches don't apply in your case since yours is not an opensocial app running in Jive.

                                   

                                  The idea is to allow users to access our app if they have valid Jive credentials without needing credentials for our app.

                                  Now I understand what you are trying to achieve Thinking through the usage flows there are two cases, in both cases I am going to assume the user starts from your service/application

                                  1. This is a new Jive user that has never granted your app access to Jive.
                                  2. A returning user that has previously granted access.

                                   

                                  Case 2 is important here, without knowing what the user id is there is no way to findout if this is a new user or returning user. So for this case, let's say you collect the user's id, but then there is still no way to verify if this is not someone impersonating some other user. If I am on the right track, I would say your service/application should have some way to challenge the user to prove who they claim they are first before accessing Jive on their behalf (using the access grant this returning user gave earlier).

                                   

                                  What this implies is that your service has to establish some relationship with the user before they can give access to Jive which is when they will use their federated credentials unrelated to the credentials they may have used to login to your service/app.

                                    • Re: Re: Using OAuth 2.0 - Seeing blank pages or browser errors for /api/core/v3/oauth2/authorize
                                      c-check

                                      Even if not federated, collecting user's credentials for another service is generally not a good idea

                                      Yes, perhaps I should not have used the term "collect" as the idea isn't to store the user's credentials as this would be a violation of their privacy, but only to have them enter the credentials and then verify them via Jive.


                                      Case 2 is important here, without knowing what the user id is there is no way to findout if this is a new user or returning user.

                                      Presuming that the user either enters their credentials and is verified by a successful token transaction or, in some ways more efficaciously, is directed to Jive before entering credentials and is returned with a successful token and a username, our application would grant them access to their data stored via that username. Effectively, the only way for that user to access their information would be via a successful token transaction with their Jive username, proving that they have valid Jive credentials. This removes the need to have credentials for our app at all as the user can rely on their Jive credentials instead.

                            • Re: Using OAuth 2.0 - Seeing blank pages or browser errors for /api/core/v3/oauth2/authorize
                              Is there some way of knowing which user has provided Jive the credentials? It's not ideal for a user to have to provide their email or username for Jive to my app, then provide it again when they are redirected to Jive

                              If I understood more about what exactly you are trying to achieve I will be able to help you better, why do you want to know user identifying information such as email or username ahead of user granting your application authorization to access Jive? In a most common form of OAuth use scenario your application already knows who the user is, that is say you are giving linkedin read access to your twitter account, you first have to login to linkedin, thus linkedin knows who you are. LinkedIn doesn't need to care about asking the user to enter their id twice.

                          • Re: Using OAuth 2.0 - Seeing blank pages or browser errors for /api/core/v3/oauth2/authorize
                            • Is there some mistake that I'm making in trying to reach the authorize page?

                            Both Ryan and Nils have already answered this one.


                            • For my add-on for OAuth 2.0, what should the meta.json have for service URL and redirect URL? Should both of them be a full domain plus URI?

                            The description for these fields is available here: Getting Started > Building a Jive Add-On. service URL is required. When your addon gets installed in Jive a POST is made to this URL which contains, among others, the client id & secret that pertains to that instance for your add-on. You may also specify an option register_url that overrides service URL as service URL could be used as a prefix for other URLs. Now to answer the actual question, yes you can provide a full domain plus URI or you can also use the %serviceURL% "macro" as prefix in values for register or redirect URL fields.


                            • For the add-on I generated random UUIDs for the add-on ID and UUID (tech partner ID?). Is this an appropriate method?

                            Yes, you are free to use any UUID generator. eg. Online UUID Generator Tool

                            1 person found this helpful