fix: clarify refresh token parameter names and improve code readability

[bashhack]

Context

While implementing the Storage interface, I discovered that several parameter names were misleading:

• Parameters named refreshTokenID and newRefreshTokenID actually contain the full token values, not IDs
• This naming inconsistency caused confusion about what values should be passed/returned
• The example implementations already use the semantically correct names (refreshToken, newRefreshToken), creating a mismatch with the interface definition

Solution

This PR aligns the interface parameter names with their actual purpose and with the existing example implementations.

Changes

1. Storage interface parameter renames:

   • TokenRequestByRefreshToken: refreshTokenID → refreshToken
   • CreateAccessAndRefreshTokens: newRefreshTokenID → newRefreshToken

2. Improved code readability in token.go:

   • Made bare returns explicit for better clarity
   • Added documentation explaining the token creation flow
   • Clarified why CreateAccessToken also returns refresh tokens

Impact

• Breaking change: No - these are parameter name changes in the interface definition only
• Behavior change: No - all logic remains unchanged
• Documentation: Improved with clearer parameter names and added explanations

Testing

• Ran existing tests (some timing-related test failures are pre-existing and unrelated to these changes)
• Verified example implementations already use the new parameter names

Definition of Ready

• [X] I am happy with the code
• [X] Short description of the feature/issue is added in the pr description
• [ ] PR is linked to the corresponding user story
• [ ] Acceptance criteria are met
• [ ] All open todos and follow ups are defined in a new ticket and justified
• [ ] Deviations from the acceptance criteria and design are agreed with the PO and documented.
• [X] No debug or dead code
• [X] My code has no repetitions
• [ ] Critical parts are tested automatically
• [ ] Where possible E2E tests are implemented
• [X] Documentation/examples are up-to-date
• [ ] All non-functional requirements are met
• [ ] Functionality of the acceptance criteria is checked manually on the dev system.

[CodeJCM]

Thanks for the addition @bashhack, we'll let you know as progress is made!

[bashhack]

Of course! Have found it so helpful to use the lib - appreciate the touchpoint with you.

Please do let me know if you run into anything and want to chat through any of my proposed changes - happy to do so 🤝

Enjoy the weekend @CodeJCM !

[elinashoko]

Heya @bashhack apologies for the delay, we're working through a lot of contributions and will get to yours soon!

[bashhack]

No rush @elinashoko - I appreciate the touchpoint. Hope the team is doing well!

[muhlemmer]

hey @bashhack thanks for the contribution.

If you'd like to have a small gift in return, please send us a mail to [email protected]. We will send you a form with questions about your address and shirt size.

[github-actions[bot]]

:tada: This PR is included in version 3.43.1 :tada:

The release is available on GitHub release

Your semantic-release bot :package::rocket: