inconsistency in sessions.authenticate_jwt return values
Closed this issue · 5 comments
we noticed that authenticate_jwt has two different return value types.
if the session_jwt passed in can be validated locally then the response looks something like this:
{
"session"=>
{
"session_id"=>"some-session-id",
"user_id"=>"some-user-id",
"started_at"=>"2023-12-15T17:23:51Z",
"last_accessed_at"=>"2023-12-15T17:48:04Z",
"expires_at"=>"2023-12-16T17:48:04Z",
"attributes"=>{
"user_agent"=>"",
"ip_address"=>""
},
"authentication_factors"=>[
{
"type"=>"password",
"delivery_method"=>"knowledge",
"last_authenticated_at"=>"2023-12-15T17:23:51Z"
}
],
"custom_claims"=>{
"https://stytch.com/organization"=>{
"organization_id"=>"some-org-id",
"slug"=>"some-slug"
}
}
}
}otherwise the return value is from authenticate and is quite different:
{"member"=> {
# member stuff here
},
"member_session"=> {
# this is identical to the session key above
},
"organization"=> {
# organization stuff here
},
"request_id"=>"request-id-test-asdfasdf-dc62-4ca0-94ab-68bc12928116",
"session_jwt"=> "session-jwt-here"
"session_token"=>"",
"status_code"=>200,
"verdict"=>nil
} Local auth should have access to the member_session, but won't necessarily have all of the other fields. Let me bundle this in with the fix in #111
Oh wait, a quick note: there's a difference in the expected shape for consumer JWT auth vs B2B JWT auth.
In consumer auth, you should have a "session" key, but in B2B auth, you should have a "member_session" key. I did see a bug in consumer here where local auth wasn't wrapping the session in the "session" key, but otherwise the other "missing" fields are expected and should be consistent with 6.6 behavior.
I'm going to leave this issue open for now to continue discussion, but v7.0.3 should fix the biggest inconsistency between the two. If this is sufficient, feel free to close this out, otherwise I'd be interested to hear what else you'd like in the local response to create parity between the two.
hey @logan-stytch
we were using b2b everywhere. the above scenario was happening previously but seems to be resolved.
i should have been clearer in the report - specifically it was weird that the session sometimes lived in session and other times under member_session. that seems to be fixed now in 7.0.3, thanks!
based on this i think you can close out this issue.
Great, glad to hear it! Sorry for the bumpy ride with 7.0 and thanks for reporting this! Let us know if you run into any other issues.