What you will be able to do
- Configure automated granting of privileges in the manifest and explain what the consumer agrees to at install
- Use app specifications so consumers approve or decline external access, OAuth, sharing and connections
- Expose a Streamlit UI through application roles and place UBAC alongside RBAC
- Run the consumer OAuth authorization flow and manage the tokens it stores in an app-owned secret
1.Permissions at install: automated granting of privileges
An app often needs to create warehouses and compute pools, read consumer data, or connect to external endpoints. With automated granting of privileges, the provider declares those privileges in the manifest. They are granted automatically when the consumer installs or upgrades the app. The feature is turned on by manifest_version: 2. Snowsight shows the requested privileges during installation. By installing, the consumer also agrees that future upgrades may grant these privileges without asking again.
manifest_version: 2
...
privileges:
- CREATE WAREHOUSE:
description: "Allows the app to create warehouses in the consumer account"These choices carry security weight on both sides. Privileges granted automatically cannot be revoked. That is why providers must explain them clearly and should request only the minimum set the app needs. The manifest must list every privilege the app requires and every API integration. On the consumer side, feature policies can restrict which objects an app is allowed to create. If a provider moves the manifest from version 2 back to 1, all automatic privileges are revoked during upgrade, but privileges the consumer granted explicitly stay in place. This change can only happen in a new version, never in a patch.
Checkpoint 1 of 7· Fill the gap
Which value turns on automated granting of privileges?
manifest_version: ?
...
privileges:
- CREATE WAREHOUSE:
description: "Allows the app to create warehouses in the consumer account"Automated granting of privileges requires manifest_version: 2. Moving back to 1 revokes the automatic grants during upgrade.
Source: docs.snowflake.com2.Consumer approval: app specifications
Automated granting lets the setup script *create* objects that reach outside the account. Using them is a separate decision that stays with the consumer. Each such object is described by an app specification, which the consumer reviews and approves or declines after installing. Specifications cover five request types: external access integrations (network endpoints limited by network rules), security integrations (for example OAuth), shares and listings (sending data to other accounts), connections (to other installed apps), and restricted operations such as overriding account-level parameters.
Checkpoint 2 of 7· Match them up
Match each app specification target to what the consumer is approving.
Tap a term, then the definition that fits it.
Each specification type controls a different way the app can reach outside its own boundary, and the consumer approves each one separately.
“Allow apps to communicate with other installed apps in the same consumer account.”Source: docs.snowflake.com
A specification has a sequence number. It goes up whenever the provider changes the definition, so the consumer can see that something changed and review it again. Edits to non-definition fields, such as the description, do not change the number. Consumers can decline a request outright or approve only part of it, for example one port out of several. Apps should therefore handle errors and tell the user which features need approval. A provider can register a specification_action lifecycle callback that runs whenever the consumer approves or declines a specification:
lifecycle_callbacks:
specification_action: callbacks.on_spec_updateCheckpoint 3 of 7· Check yourself
A provider changes only the description of an existing external access app specification. What happens to the sequence number?
Only changes to the definition increment the sequence number. Description is explicitly excluded.
“Fields that are not part of the definition, such as description, do not trigger an update to the sequence number.”Source: docs.snowflake.com
Sources3
3.Usage access: application roles, Streamlit and UBAC
Who inside the consumer account can *use* the app is controlled by application roles. They exist only inside the application object. The provider grants privileges on app objects to application roles in the setup script. These roles are implicitly granted to the application owner WITH GRANT OPTION. After installation, the owner grants them to account roles to give users access.
A Streamlit front end follows the same pattern. The setup script creates the Streamlit object and grants USAGE on it, and on its schema, to an application role. With the container runtime, the Streamlit object also names a compute pool and query warehouse that the app creates and owns. The sources do not describe a specific Streamlit *ownership parameter* for application roles. What they show is that access to the UI goes through application-role grants:
CREATE OR REPLACE STREAMLIT core.app_ui
FROM '/code_artifacts/streamlit'
MAIN_FILE = 'streamlit_app.py'
RUNTIME_NAME = 'SYSTEM$ST_CONTAINER_RUNTIME_PY3_11'
COMPUTE_POOL = myapp_streamlit_pool
QUERY_WAREHOUSE = myapp_query_warehouse;
GRANT USAGE ON SCHEMA core TO APPLICATION ROLE app_public;
GRANT USAGE ON STREAMLIT core.app_ui TO APPLICATION ROLE app_public;The two runtimes isolate viewers differently. The warehouse runtime creates a personal instance of the app for each viewer. In the container runtime, all viewers share one instance.
User-based access control (UBAC) lets an object owner grant privileges directly to individual users rather than to roles. Snowflake positions UBAC as a complement to RBAC for private development and collaboration, with building Streamlit apps as an example. UBAC gives owners no new level of privilege, since they could already grant access to any role, including PUBLIC. The provided sources do not explain how UBAC works specifically with Native Apps. Inside an app, application roles remain the documented access model.
Checkpoint 4 of 7· Check yourself
After installing an app, how does a consumer let analysts use its Streamlit UI?
The setup script grants USAGE on the Streamlit to an application role. The consumer then grants that application role to account roles.
“After installing a Snowflake Native App, consumers can grant application roles to account roles to enable access to the app.”Source: docs.snowflake.com
4.Authenticating users and OAuth tokens held in app secrets
Authentication has two layers. First, every connection to an app, including web UIs and APIs, must authenticate with a Snowflake-provided method. Any app-specific login can appear only after that succeeds, and apps should not expose public endpoints that skip Snowflake authentication. Second, when the app needs a third-party service, the SECRET_AUTHORIZATION configuration runs an OAuth authorization code flow. The consumer authenticates directly and never shares credentials with the provider.
The provider's setup script creates an API_AUTHENTICATION security integration and a secret of TYPE = oauth2 linked to it. It then creates a security-integration app specification and a configuration definition that points at the secret. The secret must be owned by the app. The application roles named in APPLICATION_ROLES need MODIFY on the secret and USAGE on the integration. Without those grants, consumers hit a permission error that gives no further context.
GRANT USAGE ON INTEGRATION oauth_integration TO APPLICATION ROLE app_user;
GRANT MODIFY ON SECRET app_schema.oauth_secret TO APPLICATION ROLE app_user;Approving the specification approves only the connection metadata; it does not complete authentication. The consumer then runs the flow in Snowsight, through request_application_configuration_value() in the app's Streamlit UI, or in SQL. The resulting tokens are stored in the secret. Code reaches them only through the SECRETS property of a UDF, procedure or SPCS container. Snowflake uses the refresh token to renew expired access tokens. If the refresh token itself expires or is revoked, external calls fail and the consumer must authenticate again.
Checkpoint 5 of 7· Put it in order
Order the consumer's SQL steps to complete the OAuth flow once the security integration specification is approved.
- 1.Find the secret name with DESCRIBE CONFIGURATION
- 2.SET CONFIGURATION oauth_config VALUE = 'configured'
- 3.Complete consent in the browser
- 4.Run SYSTEM$FINISH_OAUTH_FLOW with the redirect query string
- 5.Run SYSTEM$START_OAUTH_FLOW with the secret name
START returns the authorization URL. FINISH takes the redirect query string in the same session. Setting the value to 'configured' then fires the configuration callbacks.
“After completing the consent in the browser, execute SYSTEM$FINISH_OAUTH_FLOW in the same session with the query string from the browser redirect URL”Source: docs.snowflake.com
Checkpoint 6 of 7· Fill the gap
Which system function returns the authorization URL that starts the consumer's OAuth consent?
SELECT SYSTEM$ ? ('database_name.schema_name.secret_name');SYSTEM$START_OAUTH_FLOW takes the fully qualified secret name and returns the URL to open in the browser. FINISH_OAUTH_FLOW comes after consent.
Source: docs.snowflake.comCheckpoint 7 of 7· Exam question
A provider's Native App calls a third-party REST API that requires an API key. The provider's security reviewer rejects any design that places the key in the application package. Which design satisfies the reviewer while still working for each consumer?
Correct answer: A — Declare a SECRET reference in the manifest so each consumer binds their own secret, then read it in the UDF through the approved external access integration
- A. This is correct. A reference lets the consumer supply and control their own SECRET object, so no credential ships in package files. The function reads the secret at runtime through the approved external access integration.
- B. This is incorrect. Base64 is an encoding and not protection, and the file still ships inside the package that consumers and reviewers can read. Providers are responsible for not placing sensitive data in package files.
- C. This is incorrect. The setup script runs inside the consumer's installation and has no access to the provider's session. A literal in the script is also stored in the package, which is the exact placement the reviewer rejects.
- D. This is incorrect. Snowflake sharing flows from provider to consumer, and the provider cannot read objects in the consumer account or vice versa this way. Sending a shared key to all consumers would also defeat per-consumer credential isolation.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.A consumer can revoke privileges the app received through automated granting whenever they like.Why is that wrong?
Automatically granted privileges cannot be revoked. Consumers limit them in advance with feature policies and by reviewing the requested privileges at install.
Covered in Permissions at install: automated granting of privileges
2.Unsetting the OAuth configuration revokes the app's tokens.Why is that wrong?
The tokens stay in the secret. To stop the app from using them, decline the security integration specification, and revoke them at the third-party provider.
Covered in Authenticating users and OAuth tokens held in app secrets
3.Approving the security integration app specification completes OAuth authentication.Why is that wrong?
Approval covers only the connection metadata. The consumer must still complete the OAuth consent flow.
Covered in Authenticating users and OAuth tokens held in app secrets
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“When a provider configures an app to use manifest_version: 2 in the manifest file, automated granting of privileges is enabled.”
↩︎ Permissions at install: automated granting of privileges“Consumers can create feature policies that restrict the objects an app can create.”
↩︎ Permissions at install: automated granting of privileges“The manifest_version cannot be changed in a patch release.”
↩︎ Permissions at install: automated granting of privileges“After privileges are automatically granted during installation or upgrade, these privileges cannot be revoked.”
↩︎ Exam trap 1 - 2.
“Apps should only ask for the minimum set of privileges needed for the app to function.”
↩︎ Permissions at install: automated granting of privileges“All connections to an app, including web-based user interfaces and APIs, must first authenticate using a Snowflake-provided method of authentication.”
↩︎ Authenticating users and OAuth tokens held in app secrets - 3.
“However, because these objects enable external connections or data sharing, consumers must approve these operations when configuring the app.”
↩︎ Consumer approval: app specifications“Sequence numbers are automatically incremented when a provider changes the definition of the app specification.”
↩︎ Consumer approval: app specifications“Allow apps to communicate with other installed apps in the same consumer account.”
↩︎ Checkpoint“Fields that are not part of the definition, such as description, do not trigger an update to the sequence number.”
↩︎ Checkpoint - 4.
“Application roles are implicitly granted to the application owner WITH GRANT OPTION.”
↩︎ Usage access: application roles, Streamlit and UBAC“After installing a Snowflake Native App, consumers can grant application roles to account roles to enable access to the app.”
↩︎ Checkpoint - 5.
“All viewers share one instance of the app.”
↩︎ Usage access: application roles, Streamlit and UBAC - 6.
“UBAC complements RBAC by providing flexibility to grant privileges directly to individual users.”
↩︎ Usage access: application roles, Streamlit and UBAC“UBAC does not provide object owners with new levels of privilege.”
↩︎ Usage access: application roles, Streamlit and UBAC - 7.https://docs.snowflake.com/en/developer-guide/native-apps/app-configuration-secret-authorizationOfficial docs
“allows consumers to complete OAuth authentication directly, without sharing any credentials with the app provider.”
↩︎ Authenticating users and OAuth tokens held in app secrets“the secret must be owned by the application, and the application roles specified in APPLICATION_ROLES must have the MODIFY privilege on the secret.”
↩︎ Authenticating users and OAuth tokens held in app secrets“Snowflake uses the refresh token stored in the secret to obtain a new access token when the current access token expires.”
↩︎ Authenticating users and OAuth tokens held in app secrets“Unsetting the configuration does not invalidate or revoke the OAuth tokens stored in the secret.”
↩︎ Exam trap 2“Approving the app specification lets the consumer approve the OAuth connection metadata”
↩︎ Exam trap 3“After completing the consent in the browser, execute SYSTEM$FINISH_OAUTH_FLOW in the same session with the query string from the browser redirect URL”
↩︎ Checkpoint