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

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Matthias Wessendorf
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
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

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

Matthias Wessendorf
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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

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

Bruno Oliveira
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:

-M

On Tue, Oct 2, 2012 at 12:56 PM, Matthias Wessendorf <[hidden email]> 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




--
Matthias Wessendorf

_______________________________________________
aerogear-dev mailing list


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

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

Kris Borchers
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.

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 <[hidden email]> 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:

-M

On Tue, Oct 2, 2012 at 12:56 PM, Matthias Wessendorf <[hidden email]> 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




--
Matthias Wessendorf

_______________________________________________
aerogear-dev mailing list

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

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

Matthias Wessendorf
Hi,

On Tue, Oct 2, 2012 at 2:37 PM, Kris Borchers <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

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

Kris Borchers
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?

On Oct 2, 2012, at 8:04 AM, Matthias Wessendorf <[hidden email]> wrote:

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


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

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

Matthias Wessendorf
On Tue, Oct 2, 2012 at 3:14 PM, Kris Borchers <[hidden email]> 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 <[hidden email]> wrote:
>
>> Hi,
>>
>> On Tue, Oct 2, 2012 at 2:37 PM, Kris Borchers <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> [hidden email]
>>> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

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

Matthias Wessendorf
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 <[hidden email]> wrote:

> On Tue, Oct 2, 2012 at 3:14 PM, Kris Borchers <[hidden email]> 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 <[hidden email]> wrote:
>>
>>> Hi,
>>>
>>> On Tue, Oct 2, 2012 at 2:37 PM, Kris Borchers <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>>> 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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> [hidden email]
>>>> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> [hidden email]
>> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

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

Bruno Oliveira
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 <[hidden email]> wrote:
On Tue, Oct 2, 2012 at 3:14 PM, Kris Borchers <[hidden email]> 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 <[hidden email]> wrote:

Hi,

On Tue, Oct 2, 2012 at 2:37 PM, Kris Borchers <[hidden email]> 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 <[hidden email]> 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

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:

-M

On Tue, Oct 2, 2012 at 12:56 PM, Matthias Wessendorf <[hidden email]>
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





--
Matthias Wessendorf

_______________________________________________
aerogear-dev mailing list


_______________________________________________
aerogear-dev mailing list



_______________________________________________
aerogear-dev mailing list



--
Matthias Wessendorf

_______________________________________________
aerogear-dev mailing list


_______________________________________________
aerogear-dev mailing list



--
Matthias Wessendorf




--
Matthias Wessendorf


_______________________________________________
aerogear-dev mailing list


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev