headers
jason_h_erickson | 7 Feb 23:30

Stateless services requiring authentication in an AJAX application

 

I have a web application that has many web services and an AJAX web client as well as some mobile clients. I won't call them RESTful web services, but I'm trying to get them closer.

One problem I have is that I am trying to avoid having any application state on the server. I have that with the exception of having an authenticated session. Nothing is stored in the session except for the user's "Subject" which knows whether or not it is authenticated and who it is authenticated as.

But I want to get all the way to having no session, but that means I have to authenticate with every request. My mobile clients have no trouble doing this. (In fact, they do it already.) However, this seems to be rather tricky from a browser.

If the ENTIRE application was in one web page, then you could just store the credentials in memory. However, if you have to go from one web page to another, it starts to get hairy.

Does anyone on this list have any best practices for avoiding having any session in web applications (Human to Machine) requiring authentication?

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
mike amundsen | 8 Feb 16:23
Picon
Favicon
Gravatar

Re: Stateless services requiring authentication in an AJAX application

 

Interesting HTTP Q (not related to REST, of course)...

Here's my list of HTTP auth solutions when working w/ common browsers:

LET THE BROWSER HANDLE IT ALL
I usually use HTTPS + Basic Auth for browser apps and I let the
browser handle this detail for me. IOW, I set up the server to require
auth for the URIs and let things "flow" from there. No special coding
on the browser client at all.

SCRIPTED PRE-AUTH
Occasionally, I'll set up a scripted "pre-auth" on the browser. In
this case, I use a small JS lib to handle the base64 encoding and
prompt the user to provide user/pass locally, encode it and stuff it
into the headers for ajax calls. I do this on every call, tho and that
can get tedious.

BASIC AUTH COOKIE HACK
Finally, (and I'm not really proud of this one....) I sometimes stuff
the Base64-encoded Basic Auth value as a cookie (sheesh!) and set up
the server to peek into the cookie space before throwing a 403 upon
receiving an un-auth'ed request. The advantage here is the cookie is
retained across pages.

That's what I do.

mca
http://amundsen.com/blog/
http://twitter.com <at> mamund
http://mamund.com/foaf.rdf#me

On Tue, Feb 7, 2012 at 17:30, jason_h_erickson <jason <at> jasonerickson.com> wrote:
> I have a web application that has many web services and an AJAX web client as well as some mobile clients.  I won't call them RESTful web services, but I'm trying to get them closer.
>
> One problem I have is that I am trying to avoid having any application state on the server.  I have that with the exception of having an authenticated session.  Nothing is stored in the session except for the user's "Subject" which knows whether or not it is authenticated and who it is authenticated as.
>
> But I want to get all the way to having no session, but that means I have to authenticate with every request.  My mobile clients have no trouble doing this.  (In fact, they do it already.)  However, this seems to be rather tricky from a browser.
>
> If the ENTIRE application was in one web page, then you could just store the credentials in memory.  However, if you have to go from one web page to another, it starts to get hairy.
>
> Does anyone on this list have any best practices for avoiding having any session in web applications (Human to Machine) requiring authentication?
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
Berend de Boer | 8 Feb 19:07
Picon
Favicon
Gravatar

Re: Stateless services requiring authentication in an AJAX application

 

>>>>> "mike" == mike amundsen <mamund <at> yahoo.com> writes:

mike> LET THE BROWSER HANDLE IT ALL I usually use HTTPS + Basic
mike> Auth for browser apps and I let the browser handle this
mike> detail for me. IOW, I set up the server to require auth for
mike> the URIs and let things "flow" from there. No special coding
mike> on the browser client at all.

Any reason why http + digest doesn't fit your needs?

--
All the best,

Berend de Boer

------------------------------------------------------
Awesome Drupal hosting: https://www.xplainhosting.com/

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
mike amundsen | 8 Feb 20:02
Picon
Favicon
Gravatar

Re: Stateless services requiring authentication in an AJAX application

 

Brent:

Good point.

Digest works fine. However, when I move along this "solution scale"
(pre-auth, then cookie-hack) it's harder to continue to support
digest. that's why I didn't mention it here.

In reality, I let the server and browser sort out their preferred auth
mode (i.e. I almost always implement servers that support both Basic
and Digest, rarely OAuth).

So, yes, Digest is cool.

mca
http://amundsen.com/blog/
http://twitter.com <at> mamund
http://mamund.com/foaf.rdf#me

On Wed, Feb 8, 2012 at 13:07, Berend de Boer <berend <at> pobox.com> wrote:
>>>>>> "mike" == mike amundsen <mamund <at> yahoo.com> writes:
>
>    mike> LET THE BROWSER HANDLE IT ALL I usually use HTTPS + Basic
>    mike> Auth for browser apps and I let the browser handle this
>    mike> detail for me. IOW, I set up the server to require auth for
>    mike> the URIs and let things "flow" from there. No special coding
>    mike> on the browser client at all.
>
> Any reason why http + digest doesn't fit your needs?
>
> --
> All the best,
>
> Berend de Boer
>
>
>          ------------------------------------------------------
>          Awesome Drupal hosting: https://www.xplainhosting.com/
>

__._,_.___
Recent Activity:
.

__,_._,___
Permalink | Reply |
headers
Jason Erickson | 8 Feb 23:59

Re: Stateless services requiring authentication in an AJAX application

 

When letting the browser handle it all, how do you handle the "sign out" use case?


Also, I disagree that this is not related to REST.  A lot of services that are called RESTful but aren't are there to support AJAX.  One big reason they aren't RESTful tends to be a lack of HATEOS.  But even if you do have HATEOS in your AJAX calls, I don't know of anyone who doesn't have a session on the server to keep track of authentication, which also violates REST.  Now, the fact that I don't know anyone doing it is hardly an exhaustive search.  So the question has to do with REST thus:

  1. Can you use truly RESTful web services that require authentication in an AJAX browser-based applicatio n.  The answer to this question, from your answer below, is yes.
  2. Should you make those web services RESTful? If the answer to this is "no" then I see your point that this has nothing to do with REST (except to answer that question).  But I think the answer must be "yes, if it's feasible", so my question is about whether it is feasible/practical to do.  Is there a (good) reason no one seems to be doing it?
  • If you have a requirement to have a nice, pretty, branded login screen are you already stuck at that point? You can, with newer browsers, store the login credentials in a local data store to use on subsequent pages, but is that a good idea?
  • Say you only need to support the newer browsers and you don't have a problem storing th e credentials in a local store.  You almost certainly have another requirement to let a user "sign out" so that subsequent requests do not get automatically authenticated by the browser.  Is this possible? If it's possible, how practical is it?
  • If it is practical, how are people doing it? Are there examples to look at for best practices? You provided three examples but even you don't seem very happy with any of them.  Does anyone else have other suggestions?

    • On Feb 8, 2012, at 7:23 AM, mike amundsen wrote:

    Interesting HTTP Q (not related to REST, of course)...

    Here's my list of HTTP auth solutions when working w/ common browsers:

    LET THE BROW SER HANDLE IT ALL
    I usually use HTTPS + Basic Auth for browser apps and I let the
    browser handle this detail for me. IOW, I set up the server to require
    auth for the URIs and let things "flow" from there. No special coding
    on the browser client at all.

    SCRIPTED PRE-AUTH
    Occasionally, I'll set up a scripted "pre-auth" on the browser. In
    this case, I use a small JS lib to handle the base64 encoding and
    prompt the user to provide user/pass locally, encode it and stuff it
    into the headers for ajax calls. I do this on every call, tho and that
    can get tedious.

    BASIC AUTH COOKIE HACK
    Finally, (and I'm not really proud of this one....) I sometimes stuff
    the Base64-encoded Basic Auth value as a cookie (sheesh!) and set up
    the server to peek into t he cookie space before throwing a 403 upon
    receiving an un-auth'ed request. The advantage here is the cookie is
    retained across pages.

    That's what I do.

    mca
    http://amundsen.com/blog/
    http://twitter.com <at> mamund
    http://mamund.com/foaf.rdf#me




    On Tue, Feb 7, 2012 at 17:30, jason_h_erickson <jason <at> jasonerickson.com> wrote:
    I have a web application that has many web services and an AJAX web client as well as some mobile clients.  I won't call them RESTful web services, but I'm trying to get them closer.

    One problem I have is that I am trying to avoid having any application state on the serve r.  I have that with the exception of having an authenticated session.  Nothing is stored in the session except for the user's "Subject" which knows whether or not it is authenticated and who it is authenticated as.

    But I want to get all the way to having no session, but that means I have to authenticate with every request.  My mobile clients have no trouble doing this.  (In fact, they do it already.)  However, this seems to be rather tricky from a browser.

    If the ENTIRE application was in one web page, then you could just store the credentials in memory.  However, if you have to go from one web pag e to another, it starts to get hairy.

    Does anyone on this list have any best practices for avoiding having any session in web applications (Human to Machine) requiring authentication?



    ------------------------------------

    Yahoo! Groups Links

    <*> To visit your group on the web, go to:
       http://groups.yahoo.com/group/rest-discuss/
    blockquote>

    <*> Your email settings:
       Individual Email | Traditional

    <*> To change settings online go to:
       http://groups.yahoo.com/group/rest-discuss/join
       (Yahoo! ID required)

    <*> To change settings via email:
       rest-discuss-digest <at> yahoogroups.com
       rest-discuss-fullfeatured <at> yahoogroups.com

    <*> To unsubscribe from this group, send an email to:
       rest-discuss-unsubscribe <at> yahoogroups.com

    <*> Your use of Yahoo! Groups is subject to:
       http://docs.yahoo.com/info/terms/


    __._,_.___
    Recent Activity:
    .

    __,_._,___
    Permalink | Reply |
    headers
    Moore, Jonathan (CIM | 9 Feb 01:01
    Picon
    Favicon

    Re: Stateless services requiring authentication in an AJAX application

     

    HTTPS + login cookie is perfectly stateless from the server side if implemented correctly (as a digitally signed token). There's no reason an AJAX client can't navigate "login" and "logout" link relations and/or forms, as long as they obey the same origin policy. 

    Jon
    ........
    Jon Moore


    On Feb 8, 2012, at 5:59 PM, "Jason Erickson" <jason <at> JasonErickson.com> wrote:

     

    When letting the browser handle it all, how do you handle the "sign out" use case?


    Also, I disagree that this is not related to REST.  A lot of services that are called RESTful but aren't are there to support AJAX.  One big reason they aren't RESTful tends to be a lack of HATEOS.  But even if you do have HATEOS in your AJAX calls, I don't know of anyone who doesn't have a session on the server to keep track of authentication, which also violates REST.  Now, the fact that I don't know anyone doing it is hardly an exhaustive search.  So the question has to do with REST thus:

    1. Can you use truly RESTful web services that require authentication in an AJAX browser-based application.  The answer to this question, from your answer below, is yes.
    2. Should you make those web services RESTful? If the answer to this is "no" then I see your point that this has nothing to do with REST (except to answer that question).  But I think the answer must be "yes, if it's feasible", so my question is about whether it is feasible/practical to do.  Is there a (good) reason no one seems to be doing it?
      • If you have a requirement to have a nice, pretty, branded login screen are you already stuck at that point? You can, with newer browsers, store the login credentials in a local data store to use on subsequent pages, but is that a good idea?
      • Say you only need to support the newer browsers and you don't have a problem storing the credentials in a local store.  You almost certainly have another requirement to let a user "sign out" so that subsequent requests do not get automatically authenticated by the browser.  Is this possible? If it's possible, how practical is it?
    3. If it is practical, how are people doing it? Are there examples to look at for best practices? You provided three examples but even you don't seem very happy with any of them.  Does anyone else have other suggestions?

    On Feb 8, 2012, at 7:23 AM, mike amundsen wrote:

    Interesting HTTP Q (not related to REST, of course)...

    Here's my list of HTTP auth solutions when working w/ common browsers:

    LET THE BROWSER HANDLE IT ALL
    I usually use HTTPS + Basic Auth for browser apps and I let the
    browser handle this detail for me. IOW, I set up the server to require
    auth for the URIs and let things "flow" from there. No special coding
    on the browser client at all.

    SCRIPTED PRE-AUTH
    Occasionally, I'll set up a scripted "pre-auth" on the browser. In
    this case, I use a small JS lib to handle the base64 encoding and
    prompt the user to provide user/pass locally, encode it and stuff it
    into the headers for ajax calls. I do this on every call, tho and that
    can get tedious.

    BASIC AUTH COOKIE HACK
    Finally, (and I'm not really proud of this one....) I sometimes stuff
    the Base64-encoded Basic Auth value as a cookie (sheesh!) and set up
    the server to peek into the cookie space before throwing a 403 upon
    receiving an un-auth'ed request. The advantage here is the cookie is
    retained across pages.

    That's what I do.

    mca
    http://amundsen.com/blog/
    http://twitter.com <at> mamund
    http://mamund.com/foaf.rdf#me




    On Tue, Feb 7, 2012 at 17:30, jason_h_erickson <jason <at> jasonerickson.com> wrote:
    I have a web application that has many web services and an AJAX web client as well as some mobile clients.  I won't call them RESTful web services, but I'm trying to get them closer.

    One problem I have is that I am trying to avoid having any application state on the server.  I have that with the exception of having an authenticated session.  Nothing is stored in the session except for the user's "Subject" which knows whether or not it is authenticated and who it is authenticated as.

    But I want to get all the way to having no session, but that means I have to authenticate with every request.  My mobile clients have no trouble doing this.  (In fact, they do it already.)  However, this seems to be rather tricky from a browser.

    If the ENTIRE application was in one web page, then you could just store the credentials in memory.  However, if you have to go from one web page to another, it starts to get hairy.

    Does anyone on this list have any best practices for avoiding having any session in web applications (Human to Machine) requiring authentication?



    ------------------------------------

    Yahoo! Groups Links

    <*> To visit your group on the web, go to:
       http://groups.yahoo.com/group/rest-discuss/

    <*> Your email settings:
       Individual Email | Traditional

    <*> To change settings online go to:
       http://groups.yahoo.com/group/rest-discuss/join
       (Yahoo! ID required)

    <*> To change settings via email:
       rest-discuss-digest <at> yahoogroups.com
       rest-discuss-fullfeatured <at> yahoogroups.com

    <*> To unsubscribe from this group, send an email to:
       rest-discuss-unsubscribe <at> yahoogroups.com

    <*> Your use of Yahoo! Groups is subject to:
       http://docs.yahoo.com/info/terms/


    __._,_.___
    Recent Activity:
    .

    __,_._,___
    Permalink | Reply |
    headers
    mike amundsen | 9 Feb 01:08
    Picon
    Favicon
    Gravatar

    Re: Stateless services requiring authentication in an AJAX application

     

    Jason:

    SIGN OUT
    HTTP Auth does not support "sign-out" so, by default, i do not expect
    it when using HTTP Auth. However:
    - when using browser-based auth, this is the browser's problem
    - when using my pre-auth option or cookie-hack, i can use a flag to
    "turn off" sending the auth bits on each call

    IS THIS REST?
    as for the whole "is this REST thing" I'll only point out that the
    arch style in Fielding's dissertation has nothing to say about
    authentication patterns. That is why I made the remark at the top.
    This is not me trying to get in a dig or something, just making an
    observation.

    AJAX
    I don't really follow how using XmlHttpRequest object from a browser
    is primary to asking about using HTTP Auth or deciding if an
    implementation follows Fielding's model. For example, I've written
    quite a few "desktop" apps that don't use common browsers (i.e. all
    complied code making direct HTTP calls and parsing the responses) and
    was able to follow Fielding's model w/o any problem. As for "pretty
    login", I think I covered that in the previous post (the pre-auth).

    SESSION STATE
    I suspect part of your question really has to do w/ state-handling
    (not just auth, but the entire notion of maintaining state in a
    dist-net app). Here, Fielding's model declares "Session state is
    therefore kept entirely on the client"[1] to support the Layered
    Sytsem [2] property in his model. And, as you point out, common Web
    browsers make it tough to pull that off since,until recently, their
    support for allowing servers to send code that "writes" state data to
    the client has been limited to the cookie option. Yes, for "modern"
    browsers, there is the WebStorage API that recently hit recommendation
    status[3]. I've not used this in any production code; perhaps others
    can comment on it's usefulness.

    MY SESSION HACK FOR BROWSERS
    For cases where i need to get around the "session state on the client"
    problem common for browsers (no matter how "old" they are), I usually
    create a server-side resource that holds all the "transient state" for
    that logged in user. This is tied to the auth session and usually
    cached w/ an etag to prevent chatty traffic where possible. again,
    it's a hack, but it isolates the problem and makes it possible to:
    - make this "session state" mobile (not tied to any single server),
    - treat is as orthagonal to the server implementation (servers don't
    _do_ anything with this stuff, it's the client that must ask for and
    apply the state upon requests)
    - implementation agnostic (since it's a separated component, future
    client updates can take advantage of changes in state support w/o
    affecting existing server implementations or "older" clients.

    More than once, I've written server implementations that supported
    both "desktop" and "browser" clients. In those cases, the desktop apps
    kept their own state and the browsers used the server-side session
    resources. The server itself (that handled the business scenario)
    never knew the diff.

    Hopefully this gives you some ideas on how to come up w/ a solution
    that will work for your use cases.

    [1] http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_3
    [2] http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_6
    [3] http://www.w3.org/TR/webstorage/

    mca
    http://amundsen.com/blog/
    http://twitter.com <at> mamund
    http://mamund.com/foaf.rdf#me

    On Wed, Feb 8, 2012 at 10:23, mike amundsen <mamund <at> yahoo.com> wrote:
    > Interesting HTTP Q (not related to REST, of course)...
    >
    > Here's my list of HTTP auth solutions when working w/ common browsers:
    >
    > LET THE BROWSER HANDLE IT ALL
    > I usually use HTTPS + Basic Auth for browser apps and I let the
    > browser handle this detail for me. IOW, I set up the server to require
    > auth for the URIs and let things "flow" from there. No special coding
    > on the browser client at all.
    >
    > SCRIPTED PRE-AUTH
    > Occasionally, I'll set up a scripted "pre-auth" on the browser. In
    > this case, I use a small JS lib to handle the base64 encoding and
    > prompt the user to provide user/pass locally, encode it and stuff it
    > into the headers for ajax calls. I do this on every call, tho and that
    > can get tedious.
    >
    > BASIC AUTH COOKIE HACK
    > Finally, (and I'm not really proud of this one....) I sometimes stuff
    > the Base64-encoded Basic Auth value as a cookie (sheesh!) and set up
    > the server to peek into the cookie space before throwing a 403 upon
    > receiving an un-auth'ed request. The advantage here is the cookie is
    > retained across pages.
    >
    > That's what I do.
    >
    > mca
    > http://amundsen.com/blog/
    > http://twitter.com <at> mamund
    > http://mamund.com/foaf.rdf#me
    >
    >
    >
    >
    > On Tue, Feb 7, 2012 at 17:30, jason_h_erickson <jason <at> jasonerickson.com> wrote:
    >> I have a web application that has many web services and an AJAX web client as well as some mobile clients.  I won't call them RESTful web services, but I'm trying to get them closer.
    >>
    >> One problem I have is that I am trying to avoid having any application state on the server.  I have that with the exception of having an authenticated session.  Nothing is stored in the session except for the user's "Subject" which knows whether or not it is authenticated and who it is authenticated as.
    >>
    >> But I want to get all the way to having no session, but that means I have to authenticate with every request.  My mobile clients have no trouble doing this.  (In fact, they do it already.)  However, this seems to be rather tricky from a browser.
    >>
    >> If the ENTIRE application was in one web page, then you could just store the credentials in memory.  However, if you have to go from one web page to another, it starts to get hairy.
    >>
    >> Does anyone on this list have any best practices for avoiding having any session in web applications (Human to Machine) requiring authentication?
    >>
    >>
    >>
    >> ------------------------------------
    >>
    >> Yahoo! Groups Links
    >>
    >>
    >>

    __._,_.___
    Recent Activity:
    .

    __,_._,___
    Permalink | Reply |

    Gmane