I seem to be a bit confused as to how to get the refresh token when it's managed in the cookies. Could I get some help understanding how to do this and how it works?

So ideally you don't need to touch the refresh token When it's in the browser cookies it'll be pass implicitly to descope api during the refresh request This would ensures attackers that might succeed in injecting code on your client will not be able to complete take over the session The access token is what you should use to pass to your internal APIs to access protected resources

Ok. Many of the function calls in the server-side sdks to get the JWT require the refresh token which is why I'm confused. I'm using Python btw. Is the correct flow to redirect the user back to the login screen when the session token is valid instead of auto-refreshing if the refresh token is valid on the server-side?

Backend is different because everything is explicit, you don't have the browser to help you keep the refresh token safe, but there's less risk of injection via phishing for example so it's all good As for the logout, and any other call that requires a refresh token, if you use cookies you'll see a refresh cookie called DSR sent It should be completely seamless For python, you can take a look at our Django plugin that implements a full stack python/web framework For flutter I'll admit I'm not very familiar with it yet but perhaps @late-spoon-95735 can help with that

Well that's what I'm wondering about. So I login and the DSR gets stored in my cookies and it's not accessible from the browser (aka front-end) side. But I still want to perform tasks such as authenticating that the session is valid and what roles and tenants the user is a part of.

All of that information is on the session token

Right, I'm just confused since some of the sdk actions on both the backend and the browser side require the refresh token

Our API accepts refresh token in multiple locations It's seamless for you as a developer https://github.com/descope/react-sdk/blob/main/README.md#use-the-usedescope-usesession-and-useuser-hooks-in-your-components-in-order-to-get-authentication-state-user-details-and-utilities This example shows the react SDK You'll notice that there's no mentioning of the refresh token for logout

Interesting. This is where the flutter sdk differs I guess. Could be due to it being an alpha version

https://github.com/descope/flutter-sdk/blob/main/README.md#session-validation Looking here you can see the same rationale Refresh is optional when using cookies

That's right, we're still working on completing the flutter SDK and some functionality might be missing, like cookie support.

Thanks @late-spoon-95735.

Our python SDK does that for you

Right, but when I use the " jwt_response = descope_client.validate_session(session_token)" I get a dictionary with "amr", "drn", "exp", "iat", "iss", "rexp", "sub", "tenants", "jwt", "projectId", and "userId" and I don't know what most of these acronyms are and am unsure if the "jwt" value needs to be decoded or if the decoded version was just the rest of that dictionary

It's odd that those are empty Can you json.dumps that dict and share?

{'amr': ['oauth'], 'drn': 'DS', 'exp': 1683564666, 'iat': 1683564066, 'iss': 'P2M6NK2FWiBotudSDkLayj8yjSes', 'rexp': '2023-05-08T170106Z', 'sub': 'U2P3t0sf9miPnd3KpTsTBJ6sgKBC', 'tenants': {'T2P3ujaN9xgEYPmhobcHXISei7Z0': {'permissions': ['SSO Admin', 'User Admin'], 'roles': ['Tenant Admin']}}, 'jwt': 'eyJhbGciOiJSUzI1NiIsImtpZCI6IlAyTTZOSzJGV2lCb3R1ZFNEa0xheWo4eWpTZXMiLCJ0eXAiOiJKV1QifQ.eyJhbXIiOlsib2F1dGgiXSwiZHJuIjoiRFMiLCJleHAiOjE2ODM1NjQ2NjYsImlhdCI6MTY4MzU2NDA2NiwiaXNzIjoiUDJNNk5LMkZXaUJvdHVkU0RrTGF5ajh5alNlcyIsInJleHAiOiIyMDIzLTA1LTA4VDE3OjAxOjA2WiIsInN1YiI6IlUyUDN0MHNmOW1pUG5kM0twVHNUQko2c2dLQkMiLCJ0ZW5hbnRzIjp7IlQyUDN1amFOOXhnRVlQbWhvYmNIWElTZWk3WjAiOnsicGVybWlzc2lvbnMiOlsiU1NPIEFkbWluIiwiVXNlciBBZG1pbiJdLCJyb2xlcyI6WyJUZW5hbnQgQWRtaW4iXX19fQ.S3CvMp5JA_urDAznm9AQtJ3eFv6vFJKQwPWFXCcpGhCu7VJR_PqlPvQ1lxADabiE9OPxr8JWRXt_pM2NGBvar4ldbH28tRS4uFadh3VPMgp57-jrThrKgx7nz1gvNuBCYgWoopqYI5z2NzX0g0-q6qO0YeKRrmlctiqsWiFAqyxBdOGaz5cVLXluPIgccyutxZKD8FapAoPL0nBNs_7K31OUi5_RRpt12f4t5d3EJsMmAZ9kt-ncDHGajdJR-Xiz8O5vZ6tRWnRJKkhS2TZhBHCETkUQYFliWv_yYJQ35MP6wUpdi2UqZZp7ZNx2oNd7Atf-vn5T5DLMbBj0a-YHuw', 'projectId': '', 'userId': None}

There are helper functions for authorization for example https://github.com/descope/python-sdk#roles--permission-validation

Hi @steep-keyboard-7095, All those acronyms are the token claims (except “jwt”) and those are their meaning: amr - is the authentication method used at login time drn - is the token type, it can be DS (which is the session token) and DSR (which is the refresh token) exp - is the expiration time iat - is the token issued time iss - is the token issuer (its actually the projectId) sub - is the whom the token refers to (its actually the userId) tenants - is the info for all the tenants the user (referred to in the sub claim) belongs to and the (authorization info) roles and permissions the user has in each one of them. jwt - is just the validated jwt string For the ease of use we are extracting the projectId from the iss claim and the userId from the sub claim and just set it as keys-values in the response, it looks like we have an issue where we don’t extract those two values correctly, so in the meantime we are checking this there is a workaround you can just use the iss (instead of projectId) and sub (instead of userId) note: for the iss value you should apply the following logic (to be compatible with the values can be get by the iss claim): projectId = iss.rsplit("/")[-1]

Great thank you!!

@steep-keyboard-7095 are you up to date on the

flutter-sdk

? Refresh JWTs should pass through cookies as well

I'm not sure. In my pubspec.yaml file I have this line

descope_flutter:
    git:
      url: <https://github.com/descope/flutter-sdk.git>

Looks good, you can try to

pub get

to make sure it’s updated