Re: put in safety my Rest Web Services

Single Signon is more than just browser redirects between the server and
the client. It also involves a web application (web service call) to
verify the info retrieved from the OAuth signon attempt is valid.

I covered that here (the GETURI portion near the end):
http://www.fieldexit.com/forum/display?threadid=177

While it's not required, you're flying blind if you don't validate the
information (and Google Explicitly says to do this unless you don't mind
spoofing going on.. )

Also, I'm not sure how single signon affects to DOM (maybe showing a
userid/picture on the page?) unless you're also referring to session
objects/cookies/etc which are part of the HTTP headers, not the DOM.

Brad
www.bvstools.com


On Thu, Aug 20, 2015 at 9:26 AM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

Beat me to it, Kevin.

Sorry for the confusion. My point was meant to be in regards to "single
sign-on" which involves BROWSER "redirects" back and forth between the
server which which performs trusted "authentication" and another which
provides services; Any protocol which assumes the "client" is a browser and
manipulates the browser DOM.

Some of the previous references about oAuth were for single sign-on
implementations which manipulate the browser's DOM.

I understanding that oAuth and similar SAML based protocols are fairly
loose standards, which may be adapted for general purpose "authentication",
including for web services.
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.