"Oh no it's a long lived token that's bad"
Put it in a secret manager like 1pw cli and now start an agent...
Authn/authz is one of those things that can be really simple for pointed use cases but gets really complex when you need to support everything.
https://www.1password.dev/get-started/secure-ai-access#secur...
https://1password.com/blog/1password-trusted-access-layer-fo...
Still far from perfect tho.
The complexity in these protocols is mostly essential in nature (to the extent that you're not willing to totally reinvent the protocol, like AAuth).
Having to define what an agent can do when it identifies on my behalf is cumbersome, especially when you start to get specialised agents.
Pattern based would be too easy for AI to game, but there's got to be a service independent way to limit permissions based on role.
I am Jack's right ear - awesome you get to hear stuff.
I am jack's right hand - great you get to input stuff.
What most end users want -- for the machine to do what they want, as often as possible, while bothering them as little as possible
Windows' UAC journey is a microcosm of the space. The real long-term win is defining ground level permissions around common use cases, so that when composed they can alert as rarely as possible.
But that's an all-of-ecosystem change: the OS (providing usable boundaries), applications (updating to use minimal boundaries), and users (understanding what they'll need to approve/deny).
I really love the idea of fully enabled agents and being able to cut down on human in the loop moments.
Things like https://projects.dev/ for example.
A ton of security problems and others to solve but it's still where I want the future of all this to go.
And the individual work attached to making that transition will be done by agents.
1. workloads use existing credentials support RFC 7523 and OIDC discovery, 'trust the trust (credentials) which has already been established'. basically extend current dominant NHI paradigm.
2. DPoP mandate a signed proof for each request. so tie credential to a client-held key and specific request detail or context. viable to do at scale with #1, or does it diverge (e.g. because most #1 methods as most are not designed for DPoP?
1. Client generates a private/public keypair and uses it to generate DPoP Proofs - JWTs containing the entire public key embedded as a JWK within
2. Client presents credentials (WIF, client creds, auth code, etc.) to the Authorization Server along with a DPoP Proof
3. Authorization Server validates DPoP Proof and adds a claim to the access token containing the thumbprint - the SHA-256 hash - of the public JWK.
4. Resource Servers will now see the thumbprint claim and now know the access token needs to be presented with a fresh DPoP proof.
5. Clients generate fresh DPoP proofs and send them along with the access token
There are lots of additional details around nonces, timestamps, per-request binding, etc. but DPoP can be rolled out to any HTTP system that speaks Bearer token already.