From 46c52d0aca5724c4721108faed4d5215dc0f3b88 Mon Sep 17 00:00:00 2001 From: Himanshu Mishra Date: Thu, 6 May 2021 21:41:18 +0200 Subject: [PATCH] docs: fix doc reference links Signed-off-by: Himanshu Mishra --- docs/auth/identity-resolver.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/docs/auth/identity-resolver.md b/docs/auth/identity-resolver.md index 1e5c8dcdba..f1f99bde71 100644 --- a/docs/auth/identity-resolver.md +++ b/docs/auth/identity-resolver.md @@ -13,9 +13,10 @@ Backstage entity by a user. The ideas here were originally proposed in the RFC When a user signs in to Backstage, inside the `claims` field of their Backstage ID Token (which are standard JWT tokens) a special `ent` field is set. `ent` -contains a list of [entity references](../features/software-catalog/references), -each of which denotes an identity or a membership that is relevant to the user. -There is no guarantee that these correspond to actual existing catalog entities. +contains a list of +[entity references](../features/software-catalog/references.md), each of which +denotes an identity or a membership that is relevant to the user. There is no +guarantee that these correspond to actual existing catalog entities. Let's take an example sign-in resolver for the Google auth provider and explore how the `ent` field inside `claims` can be set.