feat: updated documentation on identity oidc auth permission

docs/documentation/platform/access-controls/attribute-based-access-controls.mdx

@@ -30,12 +30,13 @@ Attribute-based access controls are currently available for polices defined on p
     </Steps>
   </Tab>
   <Tab title="Automatically Populate Metadata">
-    For organizations using SAML for login, Infisical automatically maps metadata attributes from SAML assertions to user identities.
+    For organizations using SAML for login, Infisical automatically maps
-    This makes it easy to create policies that dynamically adapt based on the SAML user’s attributes.
+    metadata attributes from SAML assertions to user identities. This makes it
+    easy to create policies that dynamically adapt based on the SAML user’s
+    attributes.
   </Tab>
 </Tabs>
 
-
 ## Defining ABAC Policies
 
 <img src="/images/platform/access-controls/example-abac-1.png" />
@@ -49,6 +50,22 @@ The following attributes are available within project permissions:
 
 During policy execution, these placeholders are replaced by their actual values prior to evaluation.
 
+## ABAC Policies From Authentication
+
+ABAC policies can also be defined based on your identity authentication. This means you can design your authentication process using metadata provided by an external authentication provider.
+
+1. Navigate to the identity authentication table and select the Advanced section.
+2. Map the values to be included in the permission authentication key, and assign the corresponding values from the external authentication provider's data.
+3. After logging in, your access token will contain these values, and the permissions will reflect them as well.
+
+<img src="/images/platform/access-controls/abac-policies-by-auth.png" />
+
+<Info> Currently, only OIDC authentication is supported. </Info>
+
+### OIDC Authentication
+
+- **OIDC Bound Claims**: `{{ identity.auth.oidc.claims.<permission claim name> }}`
+
 ### Example Use Case
 
 #### Location-based Access Control
@@ -58,8 +75,10 @@ You could assign a `location` attribute to each user (e.g., `identity.metadata.l
 You could then structure your folders to align with this attribute and define permissions accordingly.
 
 For example, a policy might restrict access to folders matching the user's location attribute in the following pattern:
+
 ```
 /appA/{{ identity.metadata.location }}
 ```
+
 Using this structure, users can only access folders that correspond to their configured `location` attribute.
 Consequently, if a users attribute changes due to relocation, no policies need to be changed to gain access to the folders associated with their new location.