Closed mikejw closed 6 months ago
mikejw
commented
7 months ago By the way we are using a custom token provider as outlined here (even though the token comes from Cognito): https://docs.amplify.aws/javascript/build-a-backend/auth/advanced-workflows/#custom-token-providers
cwomack
commented
6 months ago @mikejw, can you try to update your auth rules to be the following and see if there is any change in behavior:
type User
@model
@auth(rules: [
{ allow: owner, provider: oidc, identityClaim: "sub::username" }
]) {
username: String!
favourites: [Int]
owner: String
}I'm still getting this kind of response from the graphql endpoint. NB: This is for path syncUsers, createUser and updateUser.
{
"data": {
"syncUsers": null
},
"errors": [
{
"path": [
"syncUsers"
],
"data": null,
"errorType": "Unauthorized",
"errorInfo": null,
"locations": [
{
"line": 2,
"column": 3,
"sourceName": null
}
],
"message": "Not Authorized to access syncUsers on type Query"
}
]
}BTW, this is whether or not a explicitly define the "owner" field or not in the schema.
chrisbonifacio
commented
6 months ago @mikejw sorry, the owner field is inconsequential. The important bit of the change we suggested was the format of the identity claim.
Did you change it to this in the auth rule?
identityClaim: "sub::username"
Oh, you did mention that the same token before the change worked in the AppSync console though... so that's strange.
Can you check the network activity in the browser and see if the syncUser request has an Authorization header with the token you'd expect?
mikejw
commented
6 months ago Hey @chrisbonifacio, yep I tried using that new identityClaim value and it didn't seem to help.
Yep, I'm using a custom token provider to make sure the authorization can happen. In AppSync I don't see any 401 unless I modify the token value with arbitrary text.
chrisbonifacio
commented
6 months ago Hmm, I'm having a hard time reproducing this myself. Can you check the owner field of a record that was created using the token and identityClaim? How is it formatted? The value of owner just has to match the value of the claim on the token.
Amplify GraphQL API's @auth directive and owner rule supports Cognito out of the box. Is there a reason why you have to use Cognito as an OIDC provider instead of a user pool?
mikejw
commented
6 months ago Hey @chrisbonifacio I'm trying to look for the data stored in DynamoDB but it shows as empty for some reason. I'm pretty sure I have seen data stored in the owner field as just the user ids that should correspond to user::sub. e.g. '562d4a8f-0a58-45fb-a873-6014759b6745'
We want to use Ionic Auth Connect and Vault components to secure the token on device with biometrics, therefore we need to be able to handle generated tokens manually.
cwomack
commented
6 months ago @mikejw, can you provide some examples of your implementation of Amplify.configure() and the token provider possibly? I think we may need some sample code to make sure we're not missing something. It would also be helpful if we could see the structure of the token payload.
mikejw
commented
6 months ago Hi @cwomack thanks but another developer on our team got it working in the end with the following auth rule:
@auth(rules: [{ allow: owner }])
I apologise as it seems I wrongly presumed that I needed to use the oidc provider due to authenticating with Cognito outside of using the Amplify authentication components.
We're all good now.
Before opening, please confirm:
JavaScript Framework
React
Amplify APIs
Authentication, GraphQL API, DataStore
Amplify Version
v6
Amplify Categories
auth, api
Backend
Amplify CLI
Environment information
Describe the bug
I have followed the docs here for creating an OIDC owner auth rule against my model: https://docs.amplify.aws/react/build-a-backend/more-features/datastore/authz-rules-setup/#owner-based-authorization-with-oidc-provider. We are using Cognito (user pool) as a generic OIDC provider and I have entered relevant details by running "amplify api update".
The full schema is here:
I have ruled out there being any issues in how data is created/read/updated by also trying this auth rule in addition to the owner one:
{ allow: private, operations: [create, read, update] }When this rule is in place everything works fine except that any user can potentially gain access to another user's data.
To highlight that issue I'm having is to do with the owner (oidc) auth rule I have been advised by someone on the Amplify discord to try running queries in ApSync with the appropriate JWT token and this does not result in any 401 errors. However any query I try to run results in unauthorized errors.
e.g.
Returns:
So what am I missing from my schema to make queries, mutations and subscriptions work?
I have also tried using "private" instead of "owner" like so:
{ allow: private, provider: oidc, identityClaim: "sub", operations: [create, read, update] }Thanks
Expected behavior
AppSync does not produce unauthorized errors as if I had used the private auth rule with all operations granted.
Reproduction steps
amplify api updateand enter details. e.g. Issuer URL, Client id etc.Code Snippet
Log output
aws-exports.js
Manual configuration
No response
Additional configuration
No response
Mobile Device
No response
Mobile Operating System
No response
Mobile Browser
No response
Mobile Browser Version
No response
Additional information and screenshots
No response