Loading ...
Sorry, an error occurred while loading the content.

Stateless services requiring authentication in an AJAX application

Expand Messages
  • jason_h_erickson
    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
    Message 1 of 7 , Feb 7, 2012
    • 0 Attachment
      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?
    • mike amundsen
      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
      Message 2 of 7 , Feb 8, 2012
      • 0 Attachment
        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@mamund
        http://mamund.com/foaf.rdf#me




        On Tue, Feb 7, 2012 at 17:30, jason_h_erickson <jason@...> 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
        >
        >
        >
      • Berend de Boer
        ... 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
        Message 3 of 7 , Feb 8, 2012
        • 0 Attachment
          >>>>> "mike" == mike amundsen <mamund@...> 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/
        • mike amundsen
          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.
          Message 4 of 7 , Feb 8, 2012
          • 0 Attachment
            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@mamund
            http://mamund.com/foaf.rdf#me




            On Wed, Feb 8, 2012 at 13:07, Berend de Boer <berend@...> wrote:
            >>>>>> "mike" == mike amundsen <mamund@...> 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/
            >
          • Jason Erickson
            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
            Message 5 of 7 , Feb 8, 2012
            • 0 Attachment
              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@mamund
              http://mamund.com/foaf.rdf#me




              On Tue, Feb 7, 2012 at 17:30, jason_h_erickson <jason@...> 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@yahoogroups.com
                 rest-discuss-fullfeatured@yahoogroups.com

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

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


            • Moore, Jonathan (CIM)
              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
              Message 6 of 7 , Feb 8, 2012
              • 0 Attachment
                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@...> 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@mamund
                http://mamund.com/foaf.rdf#me




                On Tue, Feb 7, 2012 at 17:30, jason_h_erickson <jason@...> 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@yahoogroups.com
                   rest-discuss-fullfeatured@yahoogroups.com

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

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


              • mike amundsen
                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
                Message 7 of 7 , Feb 8, 2012
                • 0 Attachment
                  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@mamund
                  http://mamund.com/foaf.rdf#me




                  On Wed, Feb 8, 2012 at 10:23, mike amundsen <mamund@...> 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@mamund
                  > http://mamund.com/foaf.rdf#me
                  >
                  >
                  >
                  >
                  > On Tue, Feb 7, 2012 at 17:30, jason_h_erickson <jason@...> 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
                  >>
                  >>
                  >>
                Your message has been successfully submitted and would be delivered to recipients shortly.