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

401 vs. 403 with authenticated users

Expand Messages
  • Jason Erickson
    This is specific to HTTP, but this seems like a good forum for it. I have a URI that is restricted to certain authenticated users. I an unauthenticated user
    Message 1 of 5 , May 20, 2011
    • 0 Attachment
      This is specific to HTTP, but this seems like a good forum for it.  

      I have a URI that is restricted to certain authenticated users.  I an unauthenticated user attempted a GET, clearly it should respond with a 401.  However, if an authenticated user attempts to GET, but that user is not permitted to access that resource, is that a 403? The spec says that "Authorization will not help and the request SHOULD NOT be repeated."  If the user is already authenticated, it is true that retrying the request will not work, however, if the user tries to re-authenticate with different credentials, he would be allowed to GET the resource.

      So is there a cut and dry answer? If not, is there a widely accepted convention?

    • Jan Algermissen
      ... No, because access to the resource is forbidden. If the user is authenticated already but is not authorized to access the resource, send a 401 - which will
      Message 2 of 5 , May 20, 2011
      • 0 Attachment
        On May 21, 2011, at 1:12 AM, Jason Erickson wrote:

        >
        >
        > This is specific to HTTP, but this seems like a good forum for it.
        >
        > I have a URI that is restricted to certain authenticated users. I an unauthenticated user attempted a GET, clearly it should respond with a 401. However, if an authenticated user attempts to GET, but that user is not permitted to access that resource, is that a 403? The spec says that "Authorization will not help and the request SHOULD NOT be repeated." If the user is already authenticated, it is true that retrying the request will not work, however, if the user tries to re-authenticate with different credentials, he would be allowed to GET the resource.
        >

        No, because access to the resource is forbidden.

        If the user is authenticated already but is not authorized to access the resource, send a 401 - which will trigger, for example a browser, to show the login dialog.

        After entering the right credentials for a login that is authorized for this resource, the server will respond 200.

        Jan


        > So is there a cut and dry answer? If not, is there a widely accepted convention?
        >
        >
        >
        >
      • Alistair Miles
        ... Hm, looking again at the HTTP spec, and in particular the definition of the 401 status code, I guess you could do it this way. But normally I do the
        Message 3 of 5 , May 25, 2011
        • 0 Attachment
          On Sat, May 21, 2011 at 07:55:05AM +0200, Jan Algermissen wrote:
          >
          > On May 21, 2011, at 1:12 AM, Jason Erickson wrote:
          >
          > >
          > >
          > > This is specific to HTTP, but this seems like a good forum for it.
          > >
          > > I have a URI that is restricted to certain authenticated users. I an unauthenticated user attempted a GET, clearly it should respond with a 401. However, if an authenticated user attempts to GET, but that user is not permitted to access that resource, is that a 403? The spec says that "Authorization will not help and the request SHOULD NOT be repeated." If the user is already authenticated, it is true that retrying the request will not work, however, if the user tries to re-authenticate with different credentials, he would be allowed to GET the resource.
          > >
          >
          > No, because access to the resource is forbidden.
          >
          > If the user is authenticated already but is not authorized to access the resource, send a 401 - which will trigger, for example a browser, to show the login dialog.
          >
          > After entering the right credentials for a login that is authorized for this resource, the server will respond 200.

          Hm, looking again at the HTTP spec, and in particular the definition of the 401
          status code, I guess you could do it this way.

          But normally I do the following:

          * If a user is not yet authenticated, and attempts to access a protected
          resource, then the response is 401.

          * If a user attempts to authenticate, but provides bad or unrecognised
          credentials, then the response is 401 again.

          * If a user is authenticated, and attempts to access a resource which they do
          not have permission to access, send a 403 with an HTML entity explaining that
          they don't have permission.

          Usually, you don't want to trigger a login dialog in a browser unless the user
          got their username or password wrong. Triggering a login dialog as a way of
          saying "you don't have permission" is potentially confusing, I would have
          thought.

          Cheers,

          Alistair

          --
          Alistair Miles
          Head of Epidemiological Informatics
          Centre for Genomics and Global Health <http://cggh.org>
          The Wellcome Trust Centre for Human Genetics
          Roosevelt Drive
          Oxford
          OX3 7BN
          United Kingdom
          Web: http://purl.org/net/aliman
          Email: alimanfoo@...
          Tel: +44 (0)1865 287669
        • Julian Reschke
          ... See and . Best regards,
          Message 4 of 5 , May 26, 2011
          • 0 Attachment
            On 2011-05-21 01:12, Jason Erickson wrote:
            > This is specific to HTTP, but this seems like a good forum for it.
            >
            >
            > I have a URI that is restricted to certain authenticated users. I an
            > unauthenticated user attempted a GET, clearly it should respond with a
            > 401. However, if an /authenticated/ user attempts to GET, but that user
            > is not permitted to access that resource, is that a 403? The spec says
            > that "Authorization will not help and the request SHOULD NOT be
            > repeated." If the user is already authenticated, it is true that
            > retrying the request will not work, however, if the user tries to
            > re-authenticate with different credentials, he would be allowed to GET
            > the resource.
            >
            > So is there a cut and dry answer? If not, is there a widely accepted
            > convention?
            > ...

            See <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/294> and
            <http://lists.w3.org/Archives/Public/ietf-http-wg/2011AprJun/0256.html>.

            Best regards, Julian
          • Craig McClanahan
            ... development experience. From the server perspective: * I do not know who you are -- 401 * I know who you are but you are not allowed to do what you
            Message 5 of 5 , May 26, 2011
            • 0 Attachment
              On Thu, May 26, 2011 at 12:35 AM, Julian Reschke <julian.reschke@...> wrote:
               

              On 2011-05-21 01:12, Jason Erickson wrote:
              > This is specific to HTTP, but this seems like a good forum for it.
              >
              >
              > I have a URI that is restricted to certain authenticated users. I an
              > unauthenticated user attempted a GET, clearly it should respond with a
              > 401. However, if an /authenticated/ user attempts to GET, but that user
              > is not permitted to access that resource, is that a 403? The spec says
              > that "Authorization will not help and the request SHOULD NOT be
              > repeated." If the user is already authenticated, it is true that
              > retrying the request will not work, however, if the user tries to
              > re-authenticate with different credentials, he would be allowed to GET
              > the resource.
              >
              > So is there a cut and dry answer? If not, is there a widely accepted
              > convention?
              > ...

              Not necessarily cut and dried, but this works for me based on real app development experience.  From the server perspective:
              * "I do not know who you are" --> 401
              * "I know who you are but you are not allowed to do what you requested" --> 403

              Craig

               

            Your message has been successfully submitted and would be delivered to recipients shortly.