2

What is the identity in the AppSync resolver context

 1 year ago
source link: https://advancedweb.hu/what-is-the-identity-in-the-appsync-resolver-context/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

What is the identity in the AppSync resolver context

The $ctx.identity contains information about the caller user and it varies depending on the authorization type

2acf7a-e45bd63b9bfc0a486857f0fbeebc7dd039d563495b865e06a619fc834e20e8a1.jpg
Author's image
Tamás Sallai
2 mins

Caller identity

AppSync supports different authorization methods and it makes the user information available for the resolvers. This is the $ctx.identity object and it is the basis for resolver-based access control and personalized responses.

Its structure depends on the authorization method used by the caller and it can be one of:

  • Cognito User Pool
  • OpenID Connect
  • Api key
  • Custom Lambda function

To make it easier to identify the authorization type used, AppSync also provides the $util.authType() function:

Returns a String describing the multi-auth type being used by a request, returning back either “IAM Authorization”, “User Pool Authorization”, “Open ID Connect Authorization”, or “API Key Authorization”.

In this article, we’ll see example for each of the possible cases and look into what are the useful attributes.

Related
Access control for Cognito users in AppSync

Cognito User pool

{
	"claims": {
		"sub": "af08acd8-f118-4016-a35d-2e47d43015a3",
		"cognito:groups": [
			"user"
		],
		"email_verified": true,
		"iss": "https://cognito-idp.eu-central-1.amazonaws.com/...",
		"cognito:username": "user1",
		"origin_jti": "c98cc3d8-0e89-490e-91b2-e0c209452d4e",
		"aud": "10f1mu8jtpi9asm1drp3a0cclo",
		"event_id": "d29a170c-4474-41e9-ae56-867eaa584604",
		"token_use": "id",
		"auth_time": 1664354661,
		"exp": 1664358261,
		"iat": 1664354661,
		"jti": "bf352d13-d551-4655-adeb-7fbb9506533f",
		"email": "[email protected]"
	},
	"defaultAuthStrategy": "DENY",
	"groups": [
		"user"
	],
	"issuer": "https://cognito-idp.eu-central-1.amazonaws.com/...",
	"sourceIp": [
		"83.173.202.165"
	],
	"sub": "af08acd8-f118-4016-a35d-2e47d43015a3",
	"username": "user1"
}
Recommended book
d5ff54-903567c7c3141d0138f9016a9121ecf6687fe7de91f874f9711622a81d924b3b.jpg
How to design, implement, and deploy GraphQL-based APIs on the AWS cloud
Book, 2022

The most important value is the sub which is the ID of the cognito user. Usually, this is the value that uniquely identifies the user and should be used for all references.

Then the username is what is set for the user but it is rarely used.

The more interesting part it the groups that helps with determining access.

Finally, the claims has all the user attributes, such as the email if set for the user.

Related
Access control for Cognito users in AppSync
{
	"accountId": "278868411450",
	"cognitoIdentityAuthProvider": null,
	"cognitoIdentityAuthType": null,
	"cognitoIdentityId": null,
	"cognitoIdentityPoolId": null,
	"sourceIp": [
		"83.173.202.165"
	],
	"userArn": "arn:aws:iam::278868411450:user/sandbox_admin",
	"username": "AIDAUB3O2IQ5MG6P2QH3Z"
}

The userArn is the unique identifier of the user, along with the username. In my experience, they are hardly used as access is determined by IAM policies and not resolvers.

OpenID Connect

{
	"claims": {
		"sub": "auth0|6335d8ca3f650861f5576bd0",
		"aud": "5Ed5N95aZN7WWvWv968mVHEvloJ7uepj",
		"iss": "https://dev-at4in79i.us.auth0.com/",
		"exp": 1664509575,
		"iat": 1664473575,
		"sid": "sBczu6aN3Q_TD73W7mjOZj_4cLl68gWp"
	},
	"issuer": "https://dev-at4in79i.us.auth0.com/",
	"sub": "auth0|6335d8ca3f650861f5576bd0"
}

The sub is the identifier of the user. Then the claims has whatever the provider returned.

Related
Use any user directory that supports OpenID Connect with AppSync

API key

null

Plain and simple, there is no information.

Custom Lambda function

{
	"resolverContext":{
		"a":"test",
		"this":"is"
	}
}

The function returns a resolverContext field and that is directly available in the identity.

Related
Configure a Lambda function to decide whether a request is allowed or not

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK