cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin (JIRA)" <>
Subject [jira] [Commented] (CXF-6572) OAuth2 Hawk Scheme requests
Date Mon, 31 Aug 2015 20:52:45 GMT


Sergey Beryozkin commented on CXF-6572:

Have you seen ?

I think as far as Hawk  is concerned this is the best we can do. Hawk was meant to go beyond
OAuth2 but I'm not sure there's much interest in that. OAuth2 now also offers a very advanced
proof of possession scheme though we do not support it yet. I like the simplicity of Hawk
and I this is why we support some parts of it.

I think there's little that we can add to what we already have. 
1) - unlikely - Hawke is not tied to Java so various default values in Java do not apply
2) - OK, I can check that and add "hawk.1.header"
3) - This is not very practical, the payload needs to be cached - if you offer a patch I can
apply it. I;d rather recommend users stick to HTTPS or use JOSE interceptors which can stream
and sign....

> OAuth2 Hawk Scheme requests
> ---------------------------
>                 Key: CXF-6572
>                 URL:
>             Project: CXF
>          Issue Type: Improvement
>          Components: JAX-RS Security
>            Reporter: Berto Murillo
>              Labels: oauth2, security
> Hi,
> References:
> Just a few general requests regarding the Hawk scheme.
> 1) It looks like the port being used in the Hawk digest is -1 if the port is unspecified.
 Is it possible to default to 80 for http and 443 for https instead of -1? For clients, I
don't think -1 is a standard behavior outside of Java if a port isn't specified and it can
be confusing.
> 2) It looks like per the Hawk website above, the header's normalization string should
begin with "hawk.1.header".
> 3) It would be great if request payload validation could be added.  It looks like that
is currently a spot where "" is being added in its place.  I want to ensure that the request
itself wasn't modified mid-request if using HTTP and not HTTPS.
> Thanks!

This message was sent by Atlassian JIRA

View raw message