Skip to content

Support other method of HoK than TOKB #75

Closed
Closed
Support other method of HoK than TOKB#75
Assignees
sakimura
Labels
component: FAPI 1: AdvancedFAPI 1: Advancedmigrated-from-bitbucketMigrated from Bitbucketpriority: majorMajor prioritytype: bugBug report

Description

@bitbucket-import-issues
bitbucket-import-issues
bot
opened on Jul 2, 2026

Originally submitted by Nat (Nat Sakimura) on 2017-03-03

There are cases that you want to have other way of HoK than TOKB, e.g., In a platform that cannot support Token Binding, or when TLS is terminated before the OAuth server.

So, only HoK should be required and not TOKB. TOKB should be made into an option to support HoK.

Bitbucket status: closed

Bitbucket origin: issue 75

Activity

  1. bitbucket-import-issues
    closed this as completedon Jul 2, 2026

  2. bitbucket-import-issues commented on Jul 2, 2026

    @bitbucket-import-issues
    bitbucket-import-issuesBot
    on Jul 2, 2026
    Author

    Originally submitted by Nat (Nat Sakimura) on 2017-03-03

    Re: #75

    → <<cset 43d7386>>

  3. bitbucket-import-issues commented on Jul 2, 2026

    @bitbucket-import-issues
    bitbucket-import-issuesBot
    on Jul 2, 2026
    Author

    Originally submitted by Nat (Nat Sakimura) on 2017-03-03

    Suggested alternative HoK method.

    Key Distribution

    https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-03

    How to use it...

    There is draft-ietf-oauth-signed-http-request but I think that's an overkill.
    We just want to authenticate+authorize the client against resource endpoint.
    So, something very short and sweet should be created.

    In essence,

    • Client either makes or gets nonce. Typically by hitting the resource, it gets a nonce in "401 Unauthorized" response. e.g.,
    #!http

    HTTP/1.0 401 Unauthorized
    Server: HTTPd/0.9
    Date: Wed, 14 March 2015 09:26:53 GMT
    WWW-Authenticate: Named nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093"
    • Client signs the nonce and put it in the Authorize header together with the access token. e.g.,
    #!http
    GET /resource/1234 HTTP/1.0
    Host: server.example.com
    Authorization: Named at="access.token.jwt", s="jws.of.nonce"

  4. bitbucket-import-issues commented on Jul 2, 2026

    @bitbucket-import-issues
    bitbucket-import-issuesBot
    on Jul 2, 2026
    Author

    Originally submitted by ve7jtb (John Bradley) on 2017-03-03

    Brian and I discussed this approach last year at the security workshop.

    This would also require changes to the RS.

    It is probably better than Justins proposal.

    It would work with symetric or asymetric keys.

    The thing we questioned was spec overload.
    Will people do this, token binding (basically this but the nonce is the EKM) and mutual TLS?

  5. bitbucket-import-issues commented on Jul 2, 2026

    @bitbucket-import-issues
    bitbucket-import-issuesBot
    on Jul 2, 2026
    Author

    Originally submitted by SaschaZeGerman (Sascha Preibisch) on 2017-03-10

    I think changes to the resource server are not too concerning. FAPI API's are new API's that have to be implemented anyways.

  6. bitbucket-import-issues commented on Jul 2, 2026

    @bitbucket-import-issues
    bitbucket-import-issuesBot
    on Jul 2, 2026
    Author

    Originally submitted by Nat (Nat Sakimura) on 2017-03-21

    So, just to update, OAuth JPOP is available as

  7. bitbucket-import-issues
    added
    type: bugBug report
    priority: majorMajor priority
    migrated-from-bitbucketMigrated from Bitbucket
    component: FAPI 1: AdvancedFAPI 1: Advanced
    on Jul 2, 2026

  8. bitbucket-import-issues commented on Jul 2, 2026

    @bitbucket-import-issues
    bitbucket-import-issuesBot
    on Jul 2, 2026
    Author

    Originally submitted by Nat (Nat Sakimura) on 2017-03-21

    Financial_API_WD_002.md Re: #75 . s/HOKTBD/JPOP\

    → <>

  9. bitbucket-import-issues commented on Jul 2, 2026

    @bitbucket-import-issues
    bitbucket-import-issuesBot
    on Jul 2, 2026
    Author

    Originally submitted by Nat (Nat Sakimura) on 2017-03-29

    Reviewed JPOP in the Monday OAuth session.

    There was a great desire to do only one way.

    Subsequently, we had a design F2F meeting among people interested on Tuesday and came to the conclusion to
    just go with x5t#s256 cnf method. This means we do not need Signature Method anymore.
    Also, we will merge with X.509 client authentication draft so that developer needs to only read a single document.

    Brian Campbell is working on it right now to be reviewed in Friday session.

    Basically, what happens is the following:

    1. the token endpoint gets the content of SSL_CLIENT_CERT, which is a PEM version of the client cert and convert it to DER and take sha256.
    2. Associate it with the access token. (Format is proprietary to the authorization server and the resource)
    3. Return the access token.
    4. Then, the client just sends the access token like bearer token but over the client cert authenticated channel.
    5. Upon receipt of it, the resource gets SSL_CLIENT_CERT and calculates x5t#s256 and compares it with the x5t#s256 that is associated with the access token.

    The rationale for using x5t#sha256 are following:

    We could have done it with SSL_CLIENT_M_SERIAL and SSL_CLIENT_I_DN but this will not be applicable when self issued certificates are to be used e.g., the mobile applications. x5t#s256 will be more robust.

    ASK: Would we get a push back from OBS that we do not use DN?

  10. bitbucket-import-issues commented on Jul 2, 2026

    @bitbucket-import-issues
    bitbucket-import-issuesBot
    on Jul 2, 2026
    Author

    Originally submitted by ve7jtb (John Bradley) on 2017-03-29

    We are still checking The DN at the AS.

    They can still validate the cert in any way they like at the RS.

    From a security point of view comparing the DN or a hash of the DN is equivalent. The hash of the cert is potentially more secure as it stops most of the validation errors at the RS.

  11. bitbucket-import-issues commented on Jul 2, 2026

    @bitbucket-import-issues
    bitbucket-import-issuesBot
    on Jul 2, 2026
    Author

    Originally submitted by Nat (Nat Sakimura) on 2017-04-04

    MTLS draft will be going to be OAuth WG item.

  12. bitbucket-import-issues commented on Jul 2, 2026

    @bitbucket-import-issues
    bitbucket-import-issuesBot
    on Jul 2, 2026
    Author

    Originally submitted by dgtonge (Dave Tonge) on 2017-04-04

    We discussed on the call to update the reference to JPOP - to the new MA TLS draft:
    https://www.ietf.org/id/draft-campbell-oauth-mtls-00.txt

  13. bitbucket-import-issues commented on Jul 2, 2026

    @bitbucket-import-issues
    bitbucket-import-issuesBot
    on Jul 2, 2026
    Author

    Originally submitted by dgtonge (Dave Tonge) on 2017-04-26

    This can be closed as the change has been made

  14. sakimura
    self-assigned this
    on Jul 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

component: FAPI 1: AdvancedFAPI 1: Advancedmigrated-from-bitbucketMigrated from Bitbucketpriority: majorMajor prioritytype: bugBug report

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions