Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PeeringDB OAuth token usage #6

Open
jramseyer opened this issue Jan 10, 2024 · 6 comments
Open

PeeringDB OAuth token usage #6

jramseyer opened this issue Jan 10, 2024 · 6 comments

Comments

@jramseyer
Copy link
Collaborator

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.

@job
Copy link
Member

job commented Jan 10, 2024

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.

@caguado
Copy link
Collaborator

caguado commented Jan 11, 2024

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.

@jramseyer
Copy link
Collaborator Author

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:

"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."

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?
I had thought that the token was only the ID token, and therefore, could only be used to get the identity and permissions of the user, as described in the OpenID spec here: https://openid.net/specs/openid-connect-core-1_0.html

From what I can understand from here: https://docs.peeringdb.com/howto/authenticate/
OAuth can be used to verify your identity, but other endpoints are behind user/pass or API-key-based authentication.

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.

jramseyer added a commit that referenced this issue Jan 11, 2024
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
@grizz
Copy link
Member

grizz commented Jan 12, 2024

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)

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.

@grizz
Copy link
Member

grizz commented Jan 12, 2024

Err, posted too quickly and missed a paragraph.

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?

That's correct.

I had thought that the token was only the ID token, and therefore, could only be used to get the identity and permissions of the user, as described in the OpenID spec here: https://openid.net/specs/openid-connect-core-1_0.html

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.

jramseyer added a commit that referenced this issue Jan 12, 2024
@jramseyer
Copy link
Collaborator Author

That's right, I remember we decided it was OIDC at NANOG88, I think.

I updated the security considerations section here: #8
Of course, if we discover we are using the tokens incorrectly, we can edit or scrap this section, but I figured I would keep the draft up to date for now. Let me know if that looks sensible.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants