PeeringDB OAuth token usage #6
Comments
|
Yeah, this type of issue is exactly why I think that also mentioning RPKI-based authentication as a option will resolve some trust issues: with RPKI the trust arc is build directly between the two parties, without an intermediate. If the draft offers multiple ways to establish trust between parties, consumers of this technology can choose what risk appetite they have and whether they will offer one or all auth options. |
|
About the trust via PeeringDB's OAuth2/OIDC (or any other third party for the matter), what I referred to in the call is that we should probably use the standard as intended when multiple parties are involved, not only in terms of crypto validation but also adequate scoping to each consuming audience. Ref rfc8725 with one more recent example of this scenario in rfc9068. Unfortunately it is a bit more nuanced than the access tokens being just cryptographically valid, but to verify among other things whether the consuming API (resource server - RS) is the intended audience to trust the scopes the bearer claims to have. Currently the access token PeeringDB hands over to the client is for the use of the PeeringDB RS alone, unless modified to include other RSs, e.g. our collective autopeer APIs. As a counter example, having direct possession of the current access token handed over by PeeringDB means the new consuming service can in turn use it to reach to PeeringDB's API itself during the time period such token is valid. Using Id Tokens for third-party purposes would follow a similar reasoning where those tokens are not expected to be shared outside the original Oauth2 client-AS relation. I found this resource from auth0 useful to understand the nuanced context on all this. As we spoke, I'll bring more of this summarized to our next meeting. |
|
Thank you both for the quick reply! Regarding RPKI-based authentication--let me take another pass through RFC 9323 to understand it better. From discussion in issue #4, probably we should give a full spec, with alternate auth options (and cover the private peering and maintenance ideas, but that's another thread). I was trying to keep it simpler by only proposing one authentication model, but if you think the IETF audience would prefer to see all the options, we can list the full spec and discuss. PeeringDB--thanks for the article, that was a neat insight into the IETF process as well. Re:
Isn't this token only for the identity? Could the API could issue GET/DELETE requests to PeeringDB, based on the permissions of the token? From what I can understand from here: https://docs.peeringdb.com/howto/authenticate/ I guess a malicious provider might be able to take that token and use it to auth against some other server's endpoint, to incorrectly request peering? Just thinking through possibilities, I am not an expert on OAuth intricacies and best practices. I will look forward to your summary as well. |
Security Considerations, one typo. Adding a section on Security Considerations. Since we are still in discussions around security considerations for the API, I left this one somewhat ambiguous. This is by no means perfect, but now we have something. Trying to get the draft into a minimal reasonable state before we submit for March. from discussions in: #6 #4
Right, I don't think there is risk in using the access token, as this is exactly what OAuth2 was designed for, as Carlos said, we need to make sure we're using it correctly. It's been a while, and we should definitely verify that, but that is what the review is for. :) Regarding RPKI, @job we are definitely planning on supporting it in a future iteration, like Jenny says, it would need a thread just for it. Our idea is that PDB, or other OAuth2 providers can say who the party is that is doing the request (and with PeeringDB scopes, it can give some authorization for if that party is allowed to do it), while RPKI signing would prove that they're allowed to make requests. Having both would be ideal, and it would be up to the server to decide what level of authentication and authorization they require. |
|
Err, posted too quickly and missed a paragraph.
That's correct.
Yes, I think we discussed this last NANOG and realized we were technically using OIDC and not OAuth. I can double check in our implementation later, but to reiterate, as long as we're following the standards how it's supposed to be done, we should be fine. |
|
That's right, I remember we decided it was OIDC at NANOG88, I think. I updated the security considerations section here: #8 Thanks all of you for reviewing the implementation--if we are using it incorrectly, let me know and I will hold off submitting a draft. I'm planning to submit in a week or two if we can manage it. |
After our discussion today, I thought more about whether or not you could impersonate someone with the PeeringDB Token.
The token we ask for from the user is the access token, not the authorization code. Authorization code comes first, and is what you use to get a token. The token is then put in the headers of the call.
Of note: when you go to register an oauth app on PeeringDB, you get a client ID, which you pass back in order to get an authorization code.
Later, you take the authorization code, and pass that back to peeringDB to get a token.
Once you have the token, one can "forget about" the client ID (PeeringDB does not need the client ID to validate the token, it validates the token on its own). I don't believe this poses a problem to the API, as our implementation only wants the token. Clients can set up their own "token-fetching" method separately.
It turns out the lead author on OAuth comes to the IETF regularly (as it is an IETF working group), so maybe we can get his opinion as well.
Anyway, it doesn't look like you can take actions on PeeringDB with only the access token (at least from a quick look, I didn't poke too hard), but maybe @grizz would have a better idea (looking at peeringdb/peeringdb#131)
cc @caguado for discussion as well.
The text was updated successfully, but these errors were encountered: