AWS IAM IDENTITY PROVIDERS Deep Dive
iamidentityproviders #iamroles #iam #aws
π This article is part of the AWS IAM Deep Dive series.
- Part 1: IAM Users Deep Dive
- Part 2: IAM Groups Deep Dive
- Part 3: IAM Roles Deep Dive
- Part 4: IAM Policies Deep Dive
- [Part 5: IAM Identity Providers Deep Dive(https://dev.to/ntsezenelvis/identity-providers-18ka)
PART 5: IAM IDENTITY PROVIDERS
aws #iam #security #devops
1. What is an IAM Identity Provider?
An IAM Identity Provider (IdP) is a trusted external system (e.g., Okta, Azure AD, Google, GitHub, Auth0) that enables federated authentication into AWS without the need for creating long-lived IAM users.
Instead of storing AWS credentials locally, users authenticate with the IdP and assume roles in AWS through STS (Security Token Service).
2. Types of IAM Identity Providers
- SAML 2.0 β Enterprise IdPs like Okta, Azure AD, ADFS.
- OIDC (OpenID Connect) β Modern apps (Google, GitHub, Auth0).
- Cognito β AWS-managed identity provider with social login support.
- Web Identity Federation β Direct federation with STS AssumeRoleWithWebIdentity.
3. Trust Policy vs Permission Policy
π IAM roles with IdPs use two types of policies:
- Trust Policy β Defines who can assume the role (the external IdP).
- Permission Policy β Defines what actions the role can perform in AWS.
Example: Trust Policy (SAML Federation with Okta)
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:saml-provider/MyOktaIdP"
      },
      "Action": "sts:AssumeRoleWithSAML",
      "Condition": {
        "StringEquals": {
          "SAML:aud": "https://signin.aws.amazon.com/saml"
        }
      }
    }
  ]
}
4. Common Problems with Identity Providers
π΄ Misconfigured SAML metadata (expired certificate or mismatch)
π΄ Overly broad trust policies (Principal: *)
π΄ Missing MFA enforcement in federation
π΄ Roles granting excessive session durations (12h+)  
5. Best Practices
β
 Always use short-lived credentials (1β12 hours max)
β
 Enforce MFA via IdP + AWS conditions (aws:MultiFactorAuthPresent)
β
 Map IdP groups to roles in AWS (least privilege principle)
β
 Rotate SAML/OIDC metadata & thumbprints regularly
β
 Monitor STS AssumeRole events in CloudTrail  
6. Hands-On Guide
Simple Example: GitHub Actions β AWS
What we're building:
- Allow GitHub Actions to upload files to an S3 bucket
- No complex SAML setup - using OIDC (modern, simpler approach)
Step-by-Step in 4 Simple Steps
Step 1: Create OIDC Identity Provider in AWS
- Go to IAM β Identity Providers
- Click "Add Provider"
- Choose "OpenID Connect"
- 
Enter:
- 
Provider URL: https://token.actions.githubusercontent.com
- 
Audience: sts.amazonaws.com
 
- 
Provider URL: 
- Click "Add provider"
β Done! AWS now trusts GitHub.
Step 2: Create IAM Role - Trust Policy
CHANGE THIS PART:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::[YOUR-AWS-ACCOUNT-ID]:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
          "token.actions.githubusercontent.com:sub": "repo:[YOUR-GITHUB-USERNAME]/[YOUR-REPO-NAME]:ref:refs/heads/main"
        }
      }
    }
  ]
}
Change these 3 things:
- 
[YOUR-AWS-ACCOUNT-ID]β Your 12-digit AWS account number
- 
[YOUR-GITHUB-USERNAME]β Your GitHub username or organization name
- 
[YOUR-REPO-NAME]β Your repository name
Step 3: Add Permissions
- 
Attach policy: AmazonS3FullAccess
- Click "Next"
Step 4: Create Workflow File
Create: .github/workflows/deploy.yml
CHANGE THIS PART:
name: Deploy to S3
on:
  push:
    branches: [ main ]
jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write   # β KEEP THIS LINE
      contents: read
    steps:
    - name: Checkout code
      uses: actions/checkout@v3
    - name: Configure AWS credentials
      uses: aws-actions/configure-aws-credentials@v2
      with:
        role-to-assume: arn:aws:iam::[YOUR-AWS-ACCOUNT-ID]:role/github-actions-s3-deploy
        aws-region: us-east-1   # β Change region if needed
    - name: Upload to S3
      run: |
        aws s3 sync ./ s3://[YOUR-BUCKET-NAME]/
Change these 3 things:
[YOUR-AWS-ACCOUNT-ID] β Same 12-digit AWS account number
us-east-1 β Your AWS region if different
7. Industry Examples
Startup: Developers use Google OIDC federation for AWS CLI access.
Enterprise: Okta SAML federation with AWS Organizations β mapped roles per business unit.
Finance: MFA enforced on SAML federation roles for compliance (PCI, SOX).
DevOps: GitHub Actions OIDC β AssumeRole directly in AWS without storing long-lived secrets.  
8. Interview Questions
Basic:
- What is an IAM Identity Provider?
- Difference between SAML 2.0 and OIDC?
Intermediate:
- How does sts:AssumeRoleWithSAMLwork?
- Explain the difference between Trust Policy and Permission Policy.
Advanced:
- How do you scale identity federation across multiple AWS accounts?
- How do you securely rotate OIDC thumbprints?
- How do IAM IdPs integrate with AWS Organizations SCPs?
π Wrapping Up
IAM Identity Providers act as the bridge between external authentication systems and AWS IAM. They remove the need for long-lived IAM credentials and enable federated, secure, and scalable authentication.  
π Key takeaways:
- Use trust + permission policies correctly
- Enforce short-lived sessions & MFA
- Monitor & audit federation events
β Thanks for reading! If this helped:
- Leave a β€οΈ reaction and follow for more AWS/DevOps deep dives
- Drop your federation experiences/questions in the comments π¬
- Share with your team to promote SSO best practices
π Stay tuned for the next deep dive in this IAM series!
 
 
              



 
    
Top comments (0)