Skip to content

Commit 23d581a

Browse files
authored
Merge pull request github#33761 from github/repo-sync
Repo sync
2 parents 80f3d94 + 3f350ba commit 23d581a

File tree

6 files changed

+60
-11
lines changed

6 files changed

+60
-11
lines changed

content/apps/creating-github-apps/about-creating-github-apps/best-practices-for-creating-a-github-app.md

Lines changed: 14 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -74,9 +74,21 @@ An installation access token is restricted based on the {% data variables.produc
7474

7575
Your app should never use a {% data variables.product.pat_generic %} or {% data variables.product.company_short %} password to authenticate.
7676

77-
## Validate organization access for every new authentication
77+
## Authorize thoroughly and durably
7878

79-
When you use a user access token, you should track which organizations the token is authorized for. If an organization uses SAML SSO and a user has not performed SAML SSO, the user access token should not have access to that organization. You can use the `GET /user/installations` REST API endpoint to verify which organizations a user access token has access to. If the user is not authorized to access an organization, you should reject their access until they perform SAML SSO. For more information, see "[AUTOTITLE](/rest/apps/installations#list-app-installations-accessible-to-the-user-access-token)."
79+
After signing in a user, app developers must take additional steps to ensure that the user is meant to have access to the data in your system. Each sign in requires fresh checks around their memberships, access, and their current SSO status.
80+
81+
### Use the durable, unique `id` to store the user
82+
83+
{% data reusables.apps.best-practice-use-durable-id %}
84+
85+
### Validate organization access for every new authentication
86+
87+
{% data reusables.apps.best-practice-validate-org-access %}
88+
89+
### Store user data with organizational and enterprise contexts
90+
91+
{% data reusables.apps.best-practice-store-data-with-context %}
8092

8193
## Expire tokens
8294

content/apps/oauth-apps/building-oauth-apps/best-practices-for-creating-an-oauth-app.md

Lines changed: 24 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -24,6 +24,30 @@ For more information about migrating an existing {% data variables.product.prodn
2424

2525
Your {% data variables.product.prodname_oauth_app %} should only request the scopes that the app needs to perform its intended functionality. If any tokens for your app become compromised, this will limit the amount of damage that can occur. For more information, see "[AUTOTITLE](/apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps)."
2626

27+
## Authorize thoroughly and durably
28+
29+
After signing in a user, app developers must take additional steps to ensure that the user is meant to have access to the data in your system. Each sign in requires fresh checks around their memberships, access, and their current SSO status.
30+
31+
### Use the durable, unique `id` to store the user
32+
33+
{% data reusables.apps.best-practice-use-durable-id %}
34+
35+
### Validate organization access for every new authentication
36+
37+
{% data reusables.apps.best-practice-validate-org-access %}
38+
39+
### Store user data with organizational and enterprise contexts
40+
41+
{% data reusables.apps.best-practice-store-data-with-context %}
42+
43+
### Verify a user's access to your app
44+
45+
Your OAuth app can be accessed by users outside your organization or enterprise. If you intend an app to be used only by members of your organization or enterprise, you should check the user's membership status when the user signs in to your app.
46+
47+
To find the list of organizations a user is a member of, you can use the "List organizations for the authenticated user" endpoint. Then you can validate this list against a list of approved organizations for your app. For more information, see "[AUTOTITLE](/rest/orgs/orgs#list-organizations-for-the-authenticated-user)."
48+
49+
{% data reusables.emus.oauth-app-note %}
50+
2751
## Secure your app's credentials
2852

2953
With a client secret, your app can authorize a user and generate user access tokens. These tokens can be used to make API requests on behalf of a user.
@@ -54,14 +78,6 @@ In the event that your app's client secret is compromised, you will need to gene
5478

5579
In the event that user access tokens are compromised, you should immediately revoke these tokens. For more information, see "[AUTOTITLE](/rest/apps/oauth-applications#delete-an-app-token)."
5680

57-
## Verify a user's access to your organizations
58-
59-
Your OAuth app can be accessed by users outside your organization or enterprise. If you intend an app to be used only by members of your organization or enterprise, you should check the user's membership status when the user signs in to your app.
60-
61-
To find the list of organizations a user is a member of, you can use the "List organizations for the authenticated user" endpoint. Then you can validate this list against a list of approved organizations for your app. For more information, see "[AUTOTITLE](/rest/orgs/orgs#list-organizations-for-the-authenticated-user)."
62-
63-
{% data reusables.emus.oauth-app-note %}
64-
6581
## Conduct regular vulnerability scans
6682

6783
{% data reusables.apps.app-scans %}
Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,11 @@
1+
Beyond tracking user identity via the `id` field, you should retain data for the organization or enterprise each user is operating under. This will help ensure you don't leak sensitive information if a user switches roles.
2+
3+
For example:
4+
5+
1. A user is in the `Mona` organization, which requires SAML SSO, and signs into your app after performing SSO. Your app now has access to whatever the user does within `Mona`.
6+
1. The user pulls a bunch of code out of a repository in `Mona` and saves it in your app for analysis.
7+
1. Later, the user switches jobs, and is removed from the `Mona` organization.
8+
9+
When the user accesses your app, can they still see the code and analysis from the `Mona` organization in their user account?
10+
11+
This is why it's critical to track the source of the data that your app is saving. Otherwise, your app is a data protection threat for organizations, and they're likely to ban your app if they can't trust that your app correctly protects their data.
Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,7 @@
1+
When a user signs in and performs actions in your application, you have to remember which user took that action in order to grant them access to the same resources the next time they sign in.
2+
3+
To store users in your database correctly, always use the `id` of the user. This value will never change for the user or be used to point to a different user, so it ensures you are providing access to the user you intend. You can find a user's `id` with the `GET /user` REST API endpoint. See "[AUTOTITLE](/rest/users/users#get-a-user)."
4+
5+
If you store references to repositories, organizations, and enterprises, use their `id` as well to ensure your links to them remain accurate.
6+
7+
_Never_ use identifiers that can change over time, including user handles, organization slugs, or email addresses.
Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
When you use a user access token, you should track which organizations the token is authorized for. If an organization uses SAML SSO and a user has not performed SAML SSO, the user access token will not have access to that organization. You can use the `GET /user/installations` REST API endpoint to verify which organizations a user access token has access to. If the user is not authorized to access an organization, you should prevent their access to organization owned data within your own application until they perform SAML SSO. For more information, see "[AUTOTITLE](/rest/apps/installations#list-app-installations-accessible-to-the-user-access-token)."

src/frame/components/ui/MarkdownContent/stylesheets/lists.scss

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -8,6 +8,7 @@ $ol-circled-reduce-diameter: 2px;
88
> ol:not(:global(.no-styling)) {
99
// We will remove the default list style and use contrasting circled counter instead
1010
list-style: none;
11+
counter-reset: markdown-ordered-list;
1112

1213
// So that list items have the same margin regardless of `li > p` or `li > [text]`
1314
> li {
@@ -16,7 +17,8 @@ $ol-circled-reduce-diameter: 2px;
1617

1718
// This is the contrasting circled counter for the list item
1819
> li::before {
19-
content: counter(list-item);
20+
counter-increment: markdown-ordered-list;
21+
content: counter(markdown-ordered-list);
2022
float: left;
2123
width: calc(1.5rem - $ol-circled-reduce-diameter);
2224
margin-left: -2rem;

0 commit comments

Comments
 (0)