Is the client secret that Beeminder gives you when you create a new OAuth app ever used for anything at all?
When you create a new app, Beeminder tells you
Hey! This is important - store this client secret somewhere safe. We don’t store it in plain text, so after your session ends you’ll need to generate another one if you don’t have it stored somewhere.
This is at least claiming that the client secret is important. But if it is, it’s not documented very well. As far as I can see, the API documentation doesn’t mention the client secret at all.
(Also—the aforementioned message references the possibility of regenerating the client secret if it is lost. That’s not actually possible, as far as I can tell.)
A somewhat related bug—if I try to register an OAuth app, and I leave off the protocol from the redirect URL (e.g.
example.com instead of
https://example.com), submitting the form fails silently (with no indication of what the problem is.)
(You also get that same silent failure if you leave the name field or redirect URL field blank.)
I think it makes sense for us to edit the regeneration copy, pointing folks to firstname.lastname@example.org if they need to regenerate their client secret.
I’ll add an issue in our tracker about the form validation things on that page. Thanks!
(Usually, when I need to remind myself of OAuth details, I end up at https://aaronparecki.com/oauth-2-simplified/.)
Thanks for that!
Really, the core of my question is this—given that I’m currently working on an OAuth app, is there any reason why I should record the secret I was given, or is it safe to just ignore?
But beyond that—the OAuth spec is well and fine, but what does the code that’s actually running support? According to the API docs, only the “implict grant” flow is supported. (With
Given that this is the case, my original question can be rephrased: What parts of the OAuth spec does Beeminder actually implement? If it’s just the “implicit grant” authentication flow, then doesn’t that mean that the client secret isn’t used for the parts of the OAuth 2 spec that Beeminder actually implements?
Now, perhaps you’ll tell me that the docs are outdated, and that nowadays Beeminder does support
response_types other than
token. If it supports
response_type=code (despite the documentation saying that it doesn’t), then sure, the client secret could be useful for that.
Or maybe the reason for me to hang onto the client secret is that in the future you might implement
response_type=code, and when that day comes the client secret will be useful, even if today it isn’t.
But if I’m not missing anything, and if the docs are accurate, then as things stand today, with the parts of the spec OAuth 2 spec that Beeminder actually implements, the client secret doesn’t seem to be usable for anything at all.
(Adding on to that: what exactly do you mean to say about the PKCE extension? Are you saying that I can use PKCE with Beeminder? If so, perhaps that should be in the docs? It does not go without saying that Beeminder supports this extension! Especially seeing as the docs seem to directly imply the opposite, that Beeminder doesn’t support anything other than the “implict grant” flow…)
I do not think there is a strong reason for you to keep that client secret if you don’t want to. If, in the future, you need it for something, you can regenerate a new set of everything, and you should be able to swap those into your application. If you don’t think you can do that for some reason, then save the client secret in a password manager or something?
I do not really know anything more than the docs re Beeminder’s OAuth at the moment, but I do not think Beeminder currently supports PKCE.
Alright, thanks for confirming that.
You’re right, given that the client secrets can be regenerated, the point becomes moot. (But that’s also why I asked about the possibility of regeneration the client secret—on the one hand, it was claimed that it was possible, but on the other, there wasn’t actually a way to do it. But OK, I guess the answer is that they can be regenerated, but only by contacting support (for now, at least.))
So that’s fine. Yes, I could always keep the client secret in a password manager—my question was mostly about whether it’s worth even bothering to do that. (Not that there’s that much of a cost to it, just that my password manager would end up full of stuff I’d never actually use.)