[aerogear-dev] [auth] 401 vs. 403
Bruno Oliveira
bruno at abstractj.org
Tue Oct 2 09:40:51 EDT 2012
Sure thing, we can make it happen.
We can't encode it in base64 or just reply with SHA-256, we just need to discuss and see how it affects the bandwidth or the implementations on aerogear.auth.js.
I'm +1 on
- Request:
> WWW-Authenticate: AG-Token
- Response:
Authorization: AG-Token=adshjadshadsgjagsdjagdasdads
--
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile
On Tuesday, October 2, 2012 at 10:30 AM, Matthias Wessendorf wrote:
> Hey,
>
> thinking out loud... what if the 401 response on the auth endpoint
> returns one of the following
> * WWW-Authenticate: Token .....
> * WWW-Authenticate: X-AG-Token .....
> * WWW-Authenticate: AG-Token .....
>
> ... something like that...
>
> The request header to that 'login endpoint' could 'react' with something like
>
> Authorization: AG-Token token=adshjadshadsgjagsdjagdasdads
>
> ===> but that above would be Base64..... (I think...)
> OR is the plan to continue sending user/password in plain text.
>
> Marko recently said sending them in plain text makes it more obvious
> that for a login (where you send your credentials), TLS is required -
> with Base64 it may be less obvious.
>
> Which I agree on ....
>
>
> Any thoughts?
>
> -Matthias
>
>
> On Tue, Oct 2, 2012 at 3:18 PM, Matthias Wessendorf <matzew at apache.org (mailto:matzew at apache.org)> wrote:
> > On Tue, Oct 2, 2012 at 3:14 PM, Kris Borchers <kris at redhat.com (mailto:kris at redhat.com)> wrote:
> > > Ah, I see. Hmm, yeah I guess the more I think about it, 401 on auth endpoints and 403 on "Not Authorized" endpoints makes sense instead of 401. I am indifferent on the header on 401 so if we want to add it that's fine, I'll still just be checking for the 401.
> > >
> > > My next question would be, what value would we assign to the WWW-Authenticate header for non-Basic auth?
> >
> > it's also used for digest and Token (like OAuth) etc
> >
> >
> > WWW-Authenticate is not limited to basic
> >
> >
> > -M
> >
> > >
> > > On Oct 2, 2012, at 8:04 AM, Matthias Wessendorf <matzew at apache.org (mailto:matzew at apache.org)> wrote:
> > >
> > > > Hi,
> > > >
> > > > On Tue, Oct 2, 2012 at 2:37 PM, Kris Borchers <kris at redhat.com (mailto:kris at redhat.com)> wrote:
> > > > > To be honest, I don't remember the full discussion either but I am only
> > > > > concerned with 401 on the login endpoint. If we did 403 with
> > > > > WWW-Authenticate header, I would be ok with that. I think I remember
> > > > > fighting for 401 over 403 because I needed to know it was an auth error so
> > > > > if it's 403 and there is a WWW-Authenticate header, then I would know it's
> > > > > an auth error.
> > > > >
> > > >
> > > >
> > > > IMO WWW-Authenticate on 403 is wrong.
> > > >
> > > > However, WWW-Authenticate MUST be included on 401 (according to the RFC)
> > > >
> > > > Regarding endpoints:
> > > >
> > > > * 'service endpoint' (e.g. /projects, /tasks etc)
> > > > ==> I think I like what amazon does, they give back 403 with NO
> > > > WWW-Authenticate header, and tell you 'denied'. IMO that's correct for
> > > > 'service endpoints', which are protected and you don't provide the
> > > > _valid_ token
> > > >
> > > > * login endpoint:
> > > > I think that 401 fits fine here, right ?
> > > > (which perhaps... should include the WWW-Authenticate on that 401)
> > > >
> > > >
> > > > NOTE: I don't want to change the current design, as it was already
> > > > discussed - but just raising some items, while doing a deeper dive on
> > > > 'auth', because of native iOS
> > > >
> > > > -Matthias
> > > >
> > > > >
> > > > > If that is the proper way, then I will make it work on the JS side. I am all
> > > > > for making the JS side "easier" but not at the expense of doing things in a
> > > > > way people don't expect.
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > On Oct 2, 2012, at 6:42 AM, Bruno Oliveira <bruno at abstractj.org (mailto:bruno at abstractj.org)> wrote:
> > > > >
> > > > > For some reason that I don't remember now, we discussed about 401 x 403 when
> > > > > the REST authentication API was sent, people decided for 401.
> > > > >
> > > > > I'm not picky on it because this is easy to change and only related to our
> > > > > TODO. We discussed about authentication methods like amazon s3 in the past
> > > > > https://github.com/abstractj/aerogear-security/blob/deltaspike/README.md
> > > > >
> > > > > We have tons of changes to do now, my only concern at the current TODO app
> > > > > was to get it done to j1.
> > > > >
> > > > >
> > > > > --
> > > > > "The measure of a man is what he does with power" - Plato
> > > > > -
> > > > > @abstractj
> > > > > -
> > > > > Volenti Nihil Difficile
> > > > >
> > > > > On Tuesday, October 2, 2012 at 8:08 AM, Matthias Wessendorf wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > I think they return 403 since they (like us) lack the WWW-Authenticate
> > > > > header.
> > > > >
> > > > > Which is required on 401:
> > > > > http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.47
> > > > >
> > > > > -M
> > > > >
> > > > > On Tue, Oct 2, 2012 at 12:56 PM, Matthias Wessendorf <matzew at apache.org (mailto:matzew at apache.org)>
> > > > > wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > I noticed that with Amazon's S3 (for instance) they return 403 when
> > > > > you are not authorized. Not really sure, but forbidden (403) is
> > > > > perhaps fine when accessing a protected REST endpoint (versus 401) ?
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > -Matthias
> > > > >
> > > > > --
> > > > > Matthias Wessendorf
> > > > >
> > > > > blog: http://matthiaswessendorf.wordpress.com/
> > > > > sessions: http://www.slideshare.net/mwessendorf
> > > > > twitter: http://twitter.com/mwessendorf
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Matthias Wessendorf
> > > > >
> > > > > blog: http://matthiaswessendorf.wordpress.com/
> > > > > sessions: http://www.slideshare.net/mwessendorf
> > > > > twitter: http://twitter.com/mwessendorf
> > > > > _______________________________________________
> > > > > aerogear-dev mailing list
> > > > > aerogear-dev at lists.jboss.org (mailto:aerogear-dev at lists.jboss.org)
> > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > aerogear-dev mailing list
> > > > > aerogear-dev at lists.jboss.org (mailto:aerogear-dev at lists.jboss.org)
> > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > aerogear-dev mailing list
> > > > > aerogear-dev at lists.jboss.org (mailto:aerogear-dev at lists.jboss.org)
> > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Matthias Wessendorf
> > > >
> > > > blog: http://matthiaswessendorf.wordpress.com/
> > > > sessions: http://www.slideshare.net/mwessendorf
> > > > twitter: http://twitter.com/mwessendorf
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > aerogear-dev at lists.jboss.org (mailto:aerogear-dev at lists.jboss.org)
> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >
> > >
> > >
> > >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org (mailto:aerogear-dev at lists.jboss.org)
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >
> >
> >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > twitter: http://twitter.com/mwessendorf
> >
>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org (mailto:aerogear-dev at lists.jboss.org)
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20121002/ff56a57b/attachment-0001.html
More information about the aerogear-dev
mailing list