Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 10:03
    lahma commented #1146
  • 09:44
    PartyArk commented #1146
  • Oct 26 19:00
    kevinchalet commented #1138
  • Oct 26 18:16
    lahma commented #1146
  • Oct 26 17:12
    rudiv commented #1148
  • Oct 26 17:10
    rudiv commented #1148
  • Oct 26 15:34

    kevinchalet on dev

    Bump Quartz.NET to 3.2.2 (compare)

  • Oct 26 15:34
    kevinchalet closed #1150
  • Oct 26 15:16
    kevinchalet milestoned #1048
  • Oct 26 15:16
    kevinchalet demilestoned #1048
  • Oct 26 15:11
    kevinchalet labeled #1150
  • Oct 26 15:11
    kevinchalet milestoned #1150
  • Oct 26 15:11
    kevinchalet assigned #1150
  • Oct 26 15:11
    kevinchalet opened #1150
  • Oct 26 15:00
    kevinchalet commented #1146
  • Oct 26 14:36
    kevinchalet commented #1148
  • Oct 26 14:26
    rudiv commented #1148
  • Oct 26 14:07
    kevinchalet commented #1148
  • Oct 26 13:47
    rudiv commented #1148
  • Oct 26 13:47
    rudiv commented #1148
Kévin Chalet
@kevinchalet
That's like asking "why is the static files middleware not helping me figure out why my Razor page doesn't work"?
Post a repro somewhere and I'll take a look when I have a moment.
James Hancock
@JohnGalt1717
if I name it and set everything to /connect/tokenish instead of /connect/token it works fine.
well... to a point.
James Hancock
@JohnGalt1717
ya, something is overriding /connect/token and 404ing on get or post in .NET 5
Kévin Chalet
@kevinchalet
Things work fine for me on my net5.0 branch, with a good old MVC controller.
James Hancock
@JohnGalt1717
Bug in razor-server
Kévin Chalet
@kevinchalet
You see, it's not an OpenIddict issue :trollface:
Care to tell us more?
James Hancock
@JohnGalt1717
It's caching stuff in the obj folder and even a full rebuild isn't clearing it.
Kévin Chalet
@kevinchalet
Nasty.
James Hancock
@JohnGalt1717
Very. Even nastier is trying to repro it for them.
How does one get odidict to return a refresh token on a password grant request?
Kévin Chalet
@kevinchalet
Grant the offline_access scope.
James Hancock
@JohnGalt1717
I have it in the options.RegisterScopes is that what you mean?
(using the scope param on /connect/token doesn't result in it being added)
Kévin Chalet
@kevinchalet
You can also just do principal.SetScopes(request.GetScopes()) to grant all the requested scopes.
James Hancock
@JohnGalt1717
Thanks!
ValidateSecurityStampAsync(principal) fails however when trying to use the refresh token
(returns null)
James Hancock
@JohnGalt1717
should the security stamp be in the refresh_token to link it or something?
James Hancock
@JohnGalt1717
I added it to the access_token so that I could validate that the user had the same stamp which I think is important for Identity Server stuff and then wrote my own implementation in the signinmanager that checks it against the usermanager value.
My only problem now is that even though I'm returning offline_access with SetScopes on the refresh token, the refresh request is only returning an access token. Once I can get it to return a refresh token too I'm all set.
Kévin Chalet
@kevinchalet
Beta6 - that will be released tomorrow - will always return a refresh token.
Give the nightly builds a try or wait a bit.
Regarding the security stamp, watch out: it's a secret value, don't expose it to third-party APIs.
James Hancock
@JohnGalt1717
Is it not encrypted in the access token and thus safe?
Kévin Chalet
@kevinchalet
It is, but if you have third-party APIs, you'll want to disable access token encryption.
James Hancock
@JohnGalt1717
Ok, we don't. Just our own. But I'll put a note in the code.
Is there a way to kill the old refresh token or is that done automatically? Because if it is, then I don't think I need to use the security stamp for this.
James Hancock
@JohnGalt1717
So they just float around forever? How does one ensure that it doesn't use an invalid refresh token? Does HttpContext.AuthenticateAsync do that for you?
Kévin Chalet
@kevinchalet
They expire after 14 days by default, so no, not forever :smile:
And in the current bits, you can already enable rolling refresh tokens.
It will be enabled by default in beta6.
James Hancock
@JohnGalt1717
ok, so when that's enabled, once it's used, it's dead?
Kévin Chalet
@kevinchalet
Yep.
James Hancock
@JohnGalt1717
(and the access_token that was created with it is toast too?0
Kévin Chalet
@kevinchalet
Currently, yes. In beta6, no.
But they'll expire after a short period of time.
James Hancock
@JohnGalt1717
Short being minutes?
Kévin Chalet
@kevinchalet
1 hour by default.
James Hancock
@JohnGalt1717
ok. How do you kill them more quickly?
Kévin Chalet
@kevinchalet
Revoke them and enable token entry validation in the validation options?
James Hancock
@JohnGalt1717
It would be nice if it was a property on the UseRollingRefreshTokens or something that let you set the time period that the previous access_token stays valid.
Kévin Chalet
@kevinchalet
You could implement that using a custom event handler.
James Hancock
@JohnGalt1717
So what I would expect is that the access token lasts until it expires OR the associated refresh token is used. At that moment (maybe with a 1 minute grace period or something for multi-threaded requests happening during the refresh request) the access token should be revoked with no grace.
I would assume that that's how it should work. I think I might be confused with what you said.
Jure Purgar
@jurepurgar
@kevinchalet I can confirm that the refresh token lifetime bug is fixed now. I can see now that jti claim is not present in the refresh token anymore. Is there a particular reason? I was using this to track single usage of a token. Is there another claim by which token can be uniquely identified?