Authentication+identity of an external API

Hi all,

You have a lot of great products, but I’m missing the “big picture” of how all the pieces would work together. Am I missing a key documentation?

Might be easier to start with describing our need: we have a backend api (elixir graphql) and a front end (on a different sub domain) in js (react)

A user belong to an organisation and that might grant access to different entities (it’s a campaign/petition tool)

For what I understand, kratos takes care of the user registration + information about the organisations and ketos of the permissions of who can access to what (or we might keep part of it in our server)

What I’m not sure is how the APi can use that information. I was hoping for a simple JWT, but it seems that the security community has mixed feeling about it.

What is the “ory way” to let the api see if the user is authenticated and what permissions they have (or the organisation they belong to?)

Thanks to point me to the documentation and let me see the light

Lastly, is there already some integration between kratos and phoenix by any chance?

1 Like

I don’t know what phoenix is, so no there is no integration right now.

Regarding the API token / keys - for SPAs you don’t need JWTs, you can use cookies.

For API-only clients (e.g. a mobile app) we don’t have support yet in Kratos but will add it over time.

It’s a framework like express or rails but build on elixir

You mean a “normal” oauth session cookie?

That’s where I’m unclear: so I need to either write an interface on my framework (to talk to kratos) or use a separate server to handle the user management UI (based on your node example? do you have others like in go?)

Assuming a separate UX for authentication (either your oauth server or the node example) hosted on different subdomains, is this possible to share cookies between my API server and the “authentication/User management” server?

(mostly for me: seems that it’s quite close to this thread)

I am having the same issue, somehow i cant understand how my api will know who is the user and what the user able to do…

From my understanding authkeeper is a barrier between my api (rest ) and the user/token/cookie.
Authkeeper handles the request and tries to see matches ( authorization and authentication processes ) after that redirects/mutates the request or creates a new request to my public api ( rest ). At this point my api should be able to realize who is the user and what is the user capable of… But how ? no idea…

Otherwise it could be an another api that i keep asking who is the user and is the user capable of this or that from my own api by sending request and expecting response. Is it so ?

Do we handle authkeeper wrong, is it a low level library we basic developers shouldnt know or care about ? Why there is no any integration with an public api tutorial ?

I feel like it is intentional but can not able to see the reason behind it.

Thank you.

My plan/understanding was that after the user authenticate (on Kratos), we have a session token (oAuth or a JWT containing the user id + some ACL data)… but I’m not clear on how the API server can work with Kratos to get there. I might be missing something obvious

From my understanding (I am also just looking into Kratos): Once you performed the login flow you will be issued a cookie. The cookie is a JWT token, that is encrypted. This cookie will be attached to every request to the same domain (also subdomain should be possible). So on your backend, you have to encrypt the cookie (idk yet how you obtain the key for that) and then you can read the JWT. You can actually see it in the quickstart sample. The JWT looks like this:

  "session": {
    "authenticatedAt": "2020-06-03T18:01:22.519Z",
    "expiresAt": "2020-06-03T19:01:22.519Z",
    "identity": {
      "addresses": [
          "expiresAt": "2020-06-04T18:01:22.523Z",
          "id": "489e3e83-c8a8-4081-a627-ad9a1d717da4",
          "value": "[email protected]",
          "verified": true,
          "verifiedAt": "2020-06-03T18:07:40.000Z",
          "via": "email"
      "id": "69b56803-9318-431c-8334-ec39143d33b3",
      "traits": {
        "email": "[email protected]"
      "traitsSchemaId": "default",
      "traitsSchemaUrl": ""
    "issuedAt": "2020-06-03T18:01:22.519Z",
    "sid": "0349fb5d-7f57-4d04-82a3-5fad97f14ef7"

However, I also think the documentation lacks information about the cookies. Its not really mentioned (just in the Quickstart, but then also just in pictures, so I wasnt able to find it via search^^).
Also, the issued session cookie is by default valid for 1h. I wonder how would one refresh it? There is a ory_kratos_continuity cookie` attached, that I would guess is used for that. But I couldnt find any “refresh” endpoint or something like that.
It would be nice if the documentation would explain the whole lifecycle, most of the sequence diagrams, e.g. at stop after the cookie is set.

1 Like

Thanks for sharing, it clarified a lot!

What happen in case of the cookie expiring and do you have some documentation on how to refresh it before it happens (assuming a session lasting longer than one hour)?

Also, can we use the content of the JWT from another app than kratos (the API server?). Are the fields and structure stable or should we assume they can change?

AFAIK, the cookie is not the JWT, the JWT is created by Oathkeeper id_token mutator, which transforms the authentication session into a JWT for backend services behind Oathkeeper consume. For authentication, the cookies is attached to requests to Oathkeeper, Oathkeeper will validates by sending a request with that cookie to Kratos.

1 Like

Correct! If you don’t use Oathkeeper at all you’ll just have the session cookie with the /sessions/whoami call for example.