Single task/route tokens

[NotionCommotion]

I am using JWT for an API authentication and like them.  Previously, I would query both some GUID and the user's ID (which wasn't their PK but a unique key per GUID), but now I just include both the account and user's DB PK in the token.  Also, including something regarding the user's permissions, however, I still haven't bought into this approach as I don't know how to deal with changing permissions and still having some JWT with different permissions floating around.  I suppose I could save the JWT's timestamp in the DB, but that seems to eliminate the benefit of token expirations...  Sorry, back to the question at hand.

I now have a need to provide emails with a reduced subset of endpoints to either view some resource or update some status.  I don't want to make the user first go to some website and then include the JWT in the header, but instead just a single click action.  Problem is now I have their JWT which is effectively their password in some email which isn't ideal, and their is no way to ensure that the specific user was the individual that viewed the resource or performed some action.  Then I thought maybe I would make some common low access JWT and use the exact same GET routes as I would do so normally and create some new GET routes to emulate main application POST/PUT/PATCH routes.

Before going down that path, I would like to investigate other solutions.  Often single use tokens are used to reset passwords and other actions which should only performed once and this is not my need but maybe close.  I am thinking of creating a token that includes the actual resource path with URL parameters along with the HTTP method.  Since everything is in the token, I wouldn't need a typical REST path to identify the resource but would have a single endpoint to retrieve them.

I searched for related information and didn't find anything which makes me concerned I am going down a rabbit hole.  Any thoughts on how to implement this?  Thanks

[requinix]

There's a website people sign into, right? Can't you use that? Have the link take them to whatever URL and use the regular website authentication to verify identity?

[NotionCommotion]

15 hours ago, requinix said:

There's a website people sign into, right? Can't you use that? Have the link take them to whatever URL and use the regular website authentication to verify identity?

 From a ux perspective, I don't want to make the user first go to some website and then include the JWT in the header, but instead just a single click action.

[requinix]

As far as security goes, a simple link is not going to be secure. You can't verify identity, only that the person has access to the email account. Are you sure that's sufficient?
If so then your hands are basically tied: create a single-use (probably) token/random identifier and embed it into the link. You can also audit the use of the link, eg. not just by logging the usage but also whether the usage happened with a logged-in account.

For indicating the action to perform, there isn't a whole lot of difference whether the token identifier includes the action to perform or not. However, if it's not part of the token (and is in the URL) then you'll probably want validation that the user is requesting an action authorized by the token, and at that point you already have sufficient information from the token itself (given that it's designed to be used for one purpose) that you probably don't need to put it into the link anymore. So the token will inherently be identifying both the user and the action.

[NotionCommotion]

21 hours ago, requinix said:

As far as security goes, a simple link is not going to be secure. You can't verify identity, only that the person has access to the email account. Are you sure that's sufficient?

Not ultra sensitive and I think it is sufficient.

21 hours ago, requinix said:

For indicating the action to perform, there isn't a whole lot of difference whether the token identifier includes the action to perform or not. However, if it's not part of the token (and is in the URL) then you'll probably want validation that the user is requesting an action authorized by the token, and at that point you already have sufficient information from the token itself (given that it's designed to be used for one purpose) that you probably don't need to put it into the link anymore. So the token will inherently be identifying both the user and the action.

Don't fully follow.

What I am currently doing is something like the following:

APPROACH 1

$token = getJWT(['accountId'=>123, 'originalUserIdWhichProbablyShouldNotBeTrusted'=>321, 'method'=>'getSomeResource', 'args'=>['fu'=>321, 'bar'=>123]]);
sendEmail("some HTML <a href='https://myserver.com/$token'>view some resource</a>");

The webserver then redirects to index.php?token=asdfklsad;lhjfgasfljkfh89zhdxcfou8fasdbn5rw3jaksejkefhalsdfasdfasddfSADFASDSDKRJYHAHUVCNAOSDFROASYSDERHFCVOASDFR, I decode the token, and respond as appropriate.

It works fine when going to my desktop gmail account, but the links don't work when going to an iphone using the same gmail account.  Not sure if the culprit, but thinking it might be due to long URLs.

As an alternative, thinking of the following:

APPROACH 2:

$hash=md5($salt.json_encode(['method'=>'get/Some/Resource', 'args'=>['fu'=>321, 'bar'=>123]]));
$token = getJWT(['accountId'=>123, 'originalUserIdWhichProbablyShouldNotBeTrusted'=>321, 'hash'=>$hash]);
sendEmail("some HTML <a href='https://myserver.com/get/Some/Resource?token=$token&fu=321&bar=123'>view some resource</a>");

I would then decode the token and ensure that the action requested is the action in the token hash.

APPROACH 3: Alternatively, I could save the method/path and arguments in the DB when generating the email and then include the PK in the token.

Does my approach 1 and 3 reflect your statement "...you probably don't need to put it into the link anymore. So the token will inherently be identifying both the user and the action"?

[requinix]

Approach #2 sounds like #3, and they both sound like #1 but with more work.

If the token is for a single purpose and it inherently includes the necessary information to determine what that purpose is then the token by itself has everything you need.

[NotionCommotion]

Thanks requinix,  If you vote for Approach 1 and considering the fact that it is complete and working, will stay the course.