You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As [we announced][blog], we've made some important changes to the way that API consumers manage SSH keys.
8
+
9
+
## Finer-grained OAuth scopes
10
+
11
+
To help third party applications request only permissions that they need, the API now supports three new [scopes][] for working with a user's public SSH keys.
12
+
13
+
-`read:public_key` provides read access to the user's SSH keys
14
+
-`write:public_key` allows an app to read existing keys and create new ones
15
+
-`admin:public_key` enables an app to read, write, and delete keys
16
+
17
+
## Changes to `user` scope
18
+
19
+
Historically, `user` scope has provided full access to manage a user's SSH keys. Now that we have dedicated scopes for managing a user's SSH keys, we have removed those permissions from the `user` scope. Now `user` scope will no longer provide access to SSH keys. Applications that need this access should request one of the new scopes described above.
20
+
21
+
## Keys are now immutable
22
+
23
+
To simplify the security audit trail for SSH keys, we're making keys immutable. API consumers can continue to create keys and delete keys as needed, but keys can no longer be changed. To change an existing key, API consumers should delete the existing key and create a new one with the desired attributes. This change applies both to a [user's SSH keys][user-keys] and a [repository's deploy keys][deploy-keys].
24
+
25
+
## Deleting keys when revoking a token
26
+
27
+
Also any keys created via an OAuth token from this point forward will be deleted when that token is revoked.
28
+
29
+
As always, if you have any questions or feedback, [please get in touch][contact].
0 commit comments