session: add a new session token v2 by End-rey · Pull Request #350 · nspcc-dev/neofs-api

End-rey · 2025-10-20T14:57:40Z

Refs #241.

session/types.proto

refs/types.proto

session/service.proto

session/types.proto

roman-khimov · 2025-10-23T12:04:16Z

session/types.proto

+      ObjectSessionContextV2 object = 6 [json_name = "object"];
+
+      // ContainerService authorization context.
+      ContainerSessionContextV2 container = 7 [json_name = "container"];


Maybe we can have a single set of object/container operations? I'm not sure what this separation buys us.

roman-khimov

But it looks good, pretty simple but powerful structure.

session/types.proto

roman-khimov

Good otherwise. ID is not critical, but I just don't see any use for it. Maybe @carpawell or @cthulhu-rider do.

roman-khimov · 2025-12-04T18:58:59Z

session/types.proto

+    uint32 version = 1 [json_name = "version"];
+
+    // Token identifier (UUIDv4 in binary form).
+    bytes id = 2 [json_name = "id"];


Can be uint32 nonce. We have no use for this ID other than to prevent collisions.

does anyone see usecase for creating additional token that differs only in id?

I treat it like a transaction nonce. Same version, same policy, same everything, but we want to have a different ID of course. For that UUID is an overkill.

But why would anyone want to create the same token with different ID is a mystery. Maybe it can happen accidentally though. Like some code has lost the old token and then it creates a new one.

what do you suggest to use as a token id? currenlty, a pair of owner/tokenID is used in node's cache. hash body?

And that's more secure, because UUID can be reused in completely different tokens, it should never be used for caching.

tbh, never liked uuid and the way it was gotten from the user without any uniqueness guarantees. support dropping it

currently, sys behavior is identical for two tokens that differ only in id. For example, the fact that some token was lost and recreated on user side (this is possible with RFC6979 signature scheme) still cannot be verified. However, caching will require more resources

So, drop id and use for caching hash body?

Replace is with 32 bit nonce. Just in case we need some randomness. Otherwise they're identified by hashes (like containers or objects are, for example).

carpawell · 2025-12-05T10:12:31Z

session/types.proto

+  // Signature of the body by the issuer.
+  neo.fs.v2.refs.Signature signature = 2 [json_name = "signature"];
+
+  // Origin token that was delegated to create this token.


mention that delegation cannot be wider than the previous one in the chain?

carpawell · 2025-12-05T10:15:25Z

session/types.proto

+    uint32 version = 1 [json_name = "version"];
+
+    // Token identifier (UUIDv4 in binary form).
+    bytes id = 2 [json_name = "id"];


what do you suggest to use as a token id? currenlty, a pair of owner/tokenID is used in node's cache. hash body?

cthulhu-rider

how about this case

neofs-api/object/types.proto

Line 200 in ff6de9a

neo.fs.v2.session.SessionToken session_token = 9 [json_name = "sessionToken"];

?

session/types.proto

cthulhu-rider · 2025-12-05T10:36:00Z

session/types.proto

  SessionToken session_token = 5 [json_name = "sessionToken"];

+  // Session token v2 with delegation chain support.
+  // If both session_token and session_token_v2 are set, session_token_v2 takes precedence.


i'd consider such requests invalid

We once discussed that both tokens are possible and they do not interfere with each other @roman-khimov

They don't interfere in that you can use one or another, but mixing them would be strange and we can forbid it immediately to prevent any inconsistencies.

End-rey · 2025-12-05T11:58:42Z

I think we won't merge for now, just in case.

session/types.proto

Session Token v2 solves the delegation, power of attorney, and chain-of-trust problems. It enables: - Account-based authority (direct or NNS-based indirect) - Multi-account subjects (multiple entities can use same token) - Multi-verb operations (GET, PUT, DELETE in single token) - Delegation chains (verifiable like X.509 certificates) - Indirect accounts (NeoFS Name Service resolution) Refs #241. Signed-off-by: Andrey Butusov <andrey@nspcc.io>

Refs nspcc-dev/neofs-api#350

End-rey self-assigned this Oct 20, 2025

End-rey requested review from carpawell, cthulhu-rider and roman-khimov as code owners October 20, 2025 14:57

End-rey marked this pull request as draft October 20, 2025 14:57

End-rey force-pushed the new-session-token-v2 branch from e65a42a to 11f58a6 Compare October 20, 2025 15:17

carpawell reviewed Oct 21, 2025

View reviewed changes

session/types.proto Outdated Show resolved Hide resolved

session/types.proto Outdated Show resolved Hide resolved

session/types.proto Outdated Show resolved Hide resolved

End-rey force-pushed the new-session-token-v2 branch from 11f58a6 to 694d30d Compare October 22, 2025 18:58

End-rey requested a review from carpawell October 22, 2025 19:21

End-rey force-pushed the new-session-token-v2 branch 2 times, most recently from b967342 to 7a51333 Compare October 23, 2025 11:20

roman-khimov reviewed Oct 23, 2025

View reviewed changes

End-rey force-pushed the new-session-token-v2 branch from 7a51333 to 45af0fd Compare October 23, 2025 18:40

End-rey requested a review from roman-khimov October 23, 2025 18:40

End-rey force-pushed the new-session-token-v2 branch 2 times, most recently from d863037 to f7f489d Compare October 31, 2025 14:50

This was referenced Nov 1, 2025

Session token V2 nspcc-dev/neofs-sdk-go#750

Merged

Session token V2 nspcc-dev/neofs-node#3671

Merged

End-rey force-pushed the new-session-token-v2 branch from f7f489d to a4dfb59 Compare November 17, 2025 16:38

End-rey marked this pull request as ready for review November 17, 2025 21:50

roman-khimov reviewed Nov 25, 2025

View reviewed changes

session/types.proto Outdated Show resolved Hide resolved

session/types.proto Outdated Show resolved Hide resolved

session/types.proto Show resolved Hide resolved

End-rey force-pushed the new-session-token-v2 branch from a4dfb59 to 1a8c6a1 Compare November 26, 2025 16:01

End-rey requested a review from roman-khimov November 27, 2025 09:25

roman-khimov reviewed Nov 28, 2025

View reviewed changes

End-rey force-pushed the new-session-token-v2 branch from 1a8c6a1 to 5278238 Compare December 1, 2025 11:04

End-rey requested a review from roman-khimov December 1, 2025 12:10

roman-khimov reviewed Dec 1, 2025

View reviewed changes

session/types.proto Outdated Show resolved Hide resolved

session/types.proto Outdated Show resolved Hide resolved

session/types.proto Outdated Show resolved Hide resolved

session/types.proto Outdated Show resolved Hide resolved

End-rey force-pushed the new-session-token-v2 branch 2 times, most recently from b32a054 to 1642d22 Compare December 3, 2025 14:38

End-rey requested a review from roman-khimov December 3, 2025 14:38

roman-khimov previously approved these changes Dec 4, 2025

View reviewed changes

carpawell previously approved these changes Dec 5, 2025

View reviewed changes

cthulhu-rider reviewed Dec 5, 2025

View reviewed changes

End-rey dismissed stale reviews from carpawell and roman-khimov via 4190114 December 5, 2025 11:54

End-rey force-pushed the new-session-token-v2 branch from 1642d22 to 4190114 Compare December 5, 2025 11:54

End-rey requested review from carpawell, cthulhu-rider and roman-khimov December 5, 2025 11:54

End-rey force-pushed the new-session-token-v2 branch from 4190114 to b3207f5 Compare December 5, 2025 11:56

carpawell previously approved these changes Dec 5, 2025

View reviewed changes

roman-khimov reviewed Dec 5, 2025

View reviewed changes

session/types.proto Outdated Show resolved Hide resolved

End-rey dismissed carpawell’s stale review via ff19835 December 5, 2025 12:24

End-rey force-pushed the new-session-token-v2 branch from b3207f5 to ff19835 Compare December 5, 2025 12:24

End-rey requested a review from roman-khimov December 5, 2025 12:24

roman-khimov approved these changes Dec 5, 2025

View reviewed changes

cthulhu-rider approved these changes Dec 5, 2025

View reviewed changes

cthulhu-rider merged commit 2aa8bbe into master Dec 5, 2025
3 checks passed

cthulhu-rider deleted the new-session-token-v2 branch December 5, 2025 12:44

roman-khimov mentioned this pull request Dec 6, 2025

Bearer token in request classification #241

Closed

End-rey mentioned this pull request Dec 11, 2025

session: change issuer of token v2 to OwnerID #363

Merged

carpawell added a commit to nspcc-dev/neofs-sdk-go that referenced this pull request Dec 19, 2025

Session token V2 (#750)

36305f2

Refs nspcc-dev/neofs-api#350

End-rey mentioned this pull request Dec 20, 2025

object: set session token v2 to header #365

Merged

roman-khimov mentioned this pull request Jan 19, 2026

Cover new session token functionality nspcc-dev/neofs-testcases#823

Closed

Conversation

End-rey commented Oct 20, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

roman-khimov left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

roman-khimov left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cthulhu-rider left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

End-rey commented Dec 5, 2025

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development