According to the OAuth 2.0 Bearer Token Profile, when accessing a resource protected with OAuth 2.0, the bearer token can go in the HTTP Authorization header or be a form-encoded body parameter or a query parameter. If it’s a query parameter, its value must be access_token. But here, LinkedIn deviates from the OAuth 2.0 Bearer Token Profile.
Following is a request to the LinkedIn UserInfo endpoint... curl https://api.linkedin.com/v1/people/~?oauth2_access_token=AQVKwPCyJoTDl9CZl5ID9S9hig9qd0P Thanks & regards, -Prabath On Thu, Sep 25, 2014 at 11:02 AM, Prabath Siriwardena <[email protected]> wrote: > I think its true to some extent that some OAuth authorization servers (AS) > use their own configuration parameters and also some what deviate from the > OAuth specification. > > What you can do is - keep a basic OAuth 1.0 and 2.0 modules and if you see > a given AS has changed the behavior - extend from the correct OAuth module > and add the specific behavior there. > > Thanks & regards, > -Prabath > > On Thu, Sep 25, 2014 at 10:23 AM, Johann Nallathamby <[email protected]> > wrote: > >> >> >> On Thu, Sep 25, 2014 at 9:24 AM, Ravindra Ranwala <[email protected]> >> wrote: >> >>> The constraints we encountered are listed below. >>> >>> Different OAuth Providers use different OAuth versions. >>> >> >> Yes. There are two versions 1.0a and 2.0. You don't have any way around >> this because some providers still use 1.0a. >> >> >>> Different OAuth Providers expose different APIs and different >>> configuration details. >>> >> >> This cannot be true. If they are spec compliant they should expose a >> standard set of endpoints. E.g. for oauth10a there are 3 standard >> endpoints, for oauth2 there are two standard endpoints. >> >> And since OAuth is a transport level security protocol it should be very >> easy to extract all the authorization logic out from the connector. E.g. >> the Bearer access token goes as part of the Authorization header, which >> means you should be able to set it to the transport header and ESB should >> handle it in sending it out with the request if I am not mistaken. The >> connector should not worry about setting these headers even. It's the same >> for oauth1.0a, except that the message in the header is more complex. >> >> Can you be more specific when you say different APIs and different >> configurations? What you need to see is if they comply with standard OAuth >> or not. >> >>> >>> This makes it bit difficult to generalize the Authorization process >>> across different OAuth Providers. >>> >>> Thanks & Regards, >>> >>> On Thu, Sep 25, 2014 at 8:58 AM, Johann Nallathamby <[email protected]> >>> wrote: >>> >>>> +1 to externalize the authorization logic. It will also help evolve the >>>> connectors when OAuth goes out of fashion and another authorization >>>> standard rules over it. What kind of difficulties did you come across? As >>>> long as it is following OAuth 1.0a or 2.0 standard you should be able to be >>>> able to generalize your code. >>>> >>>> Thanks, >>>> Johann. >>>> >>>> On Thu, Sep 25, 2014 at 8:40 AM, Ravindra Ranwala <[email protected]> >>>> wrote: >>>> >>>>> In the iPAAS integration project for ESB, we are implementing OAuth >>>>> authorization support for different providers such as twitter, google, >>>>> salesforce, facebook,LinkedIn etc to access their resources from our iPAAS >>>>> app. Each provider has their own configuration details and APIs for this >>>>> purpose. So we found that it is very difficult to generalize our solution. >>>>> If you have any idea of generalizing the OAuth authorization process >>>>> across >>>>> different OAuth service Providers please don't hesitate to share your >>>>> ideas >>>>> with us. >>>>> >>>>> >>>>> >>>>> Thanks & Regards, >>>>> -- >>>>> Ravindra Ranwala >>>>> Software Engineer >>>>> WSO2, Inc: http://wso2.com >>>>> <http://www.google.com/url?q=http%3A%2F%2Fwso2.com&sa=D&sntz=1&usg=AFQjCNEZvyc0uMD1HhBaEGCBxs6e9fBObg> >>>>> Mobile: +94714198770 >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "WSO2 Engineering Group" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> For more options, visit https://groups.google.com/a/wso2.com/d/optout. >>>>> >>>> >>>> >>>> >>>> -- >>>> Thanks & Regards, >>>> >>>> *Johann Dilantha Nallathamby* >>>> Associate Technical Lead & Product Lead of WSO2 Identity Server >>>> Integration Technologies Team >>>> WSO2, Inc. >>>> lean.enterprise.middleware >>>> >>>> Mobile - *+94777776950* >>>> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* >>>> >>> >>> >>> >>> -- >>> Ravindra Ranwala >>> Software Engineer >>> WSO2, Inc: http://wso2.com >>> <http://www.google.com/url?q=http%3A%2F%2Fwso2.com&sa=D&sntz=1&usg=AFQjCNEZvyc0uMD1HhBaEGCBxs6e9fBObg> >>> Mobile: +94714198770 >>> >>> >> >> >> -- >> Thanks & Regards, >> >> *Johann Dilantha Nallathamby* >> Associate Technical Lead & Product Lead of WSO2 Identity Server >> Integration Technologies Team >> WSO2, Inc. >> lean.enterprise.middleware >> >> Mobile - *+94777776950* >> Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>* >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Thanks & Regards, > Prabath > > Twitter : @prabath > LinkedIn : http://www.linkedin.com/in/prabathsiriwardena > > Mobile : +94 71 809 6732 > > http://blog.facilelogin.com > http://blog.api-security.org > -- Thanks & Regards, Prabath Twitter : @prabath LinkedIn : http://www.linkedin.com/in/prabathsiriwardena Mobile : +94 71 809 6732 http://blog.facilelogin.com http://blog.api-security.org
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
