[aerogear-dev] [auth] 401 vs. 403

Tue Oct 2 09:30:15 EDT 2012

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> wrote:
> On Tue, Oct 2, 2012 at 3:14 PM, Kris Borchers <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> wrote:
>>
>>> Hi,
>>>
>>> On Tue, Oct 2, 2012 at 2:37 PM, Kris Borchers <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> 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>
>>>> 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
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> 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
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> 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