# Invalid authentication credentials when using infra.aap\_configuration.hub\_collection\_remote **URL:** \ **Category:** Get Help\ **Tags:** kubernetes, infra-config-as-code, aap, awx, galaxy-ng\ **Created:** [July 16, 2025, 2:41pm UTC](https://forum.ansible.com/t/invalid-authentication-credentials-when-using-infra-aap-configuration-hub-collection-remote/43902 "2025-07-16T14:41:31Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Beumont](https://avatars.discourse-cdn.com/v4/letter/b/ac8455/32.png) [@Beumont](https://forum.ansible.com/u/Beumont)\ **Post date:** [July 16, 2025, 2:41pm UTC](https://forum.ansible.com/t/invalid-authentication-credentials-when-using-infra-aap-configuration-hub-collection-remote/43902/1 "2025-07-16T14:41:31Z")
When running `infra.aap_configuration.hub_collection_remote` I am getting an error Playbook task output: ```sh msg: 'Authentication error: Invalid authentication credentials for /api/galaxy/_ui/v1/me/ (HTTP 401).' ``` `aap_token` is configured with a token from the admin user. `aap_hostname` is configured with the gateway url other roles from **infra.aap\_configuration** (controller settings, inventories, etc.) authenticate just fine against the same Automation Gateway. I am using ansible automation platform 2.5 on openshift. Installed collections: ```bash Collection Version ----------------------- ------------ ansible.controller 4.6.13 ansible.eda 2.8.0 ansible.hub 1.0.0 ansible.platform 2.5.20250528 awx.awx 24.6.1 cloud.common 4.2.0 community.general 10.7.0 infra.aap_configuration 3.4.1 kubernetes.core 6.0.0 ``` Variables for the role ```auto --- hub_collection_remotes: - name: test url: https://console.redhat.com/api/automation-hub/content/published/ auth_url: https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token token: "{{ rh_token }}" tls_validation: false requirements: - name: ansible.platform ``` My playbook: ```auto --- - name: Infra Dispatch role hosts: localhost connection: local gather_facts: false vars_files: - ../vaults/vault-{{ stage }} roles: - name: infra.aap_configuration.dispatch ``` ---
**Author:** ![Denney-tech](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/denney-tech/32/1556_2.png) [@Denney-tech](https://forum.ansible.com/u/Denney-tech)\ **Post date:** [November 11, 2025, 2:40pm UTC](https://forum.ansible.com/t/invalid-authentication-credentials-when-using-infra-aap-configuration-hub-collection-remote/43902/2 "2025-11-11T14:40:02Z")
I have run into essentially the same problem on OpenShift with AAP 2.6. Using the same admin user and token from CLI works just fine, but the same play as a job template to have AAP bootstrap itself fails to authenticate with the very same credential/authentication method. My only difference is the uri path in the error message: ```auto msg: "error: Error while getting server version: Invalid authentication credentials for /api/galaxy/ (HTTP 401)." ``` Edit: And just to confirm, authentication works on gateway\_\* and controller\_\* infra.aap\_configuration.dispatch roles/tasks. I don’t have any EDA configuration as code to test, so I can’t confirm whether or not EDA has any similar authentication issue. ---
**Author:** ![Denney-tech](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/denney-tech/32/1556_2.png) [@Denney-tech](https://forum.ansible.com/u/Denney-tech)\ **Post date:** [November 11, 2025, 5:42pm UTC](https://forum.ansible.com/t/invalid-authentication-credentials-when-using-infra-aap-configuration-hub-collection-remote/43902/3 "2025-11-11T17:42:46Z")
Seems to be that the issue is that the infra.aap\_configuration.hub\* roles aren’t passing the aap\_token to the ah\_token parameter, but then that might be specifically for hub tokens rather than platform tokens (even though all of the other ah\_\* options work with their aap\_\* alias). If the latter is the case, then the issue is with ansible.hub upstream. In anycase, I was able to work around this by providing the username and password in the Red Hat Automation Platform credential type (but not an oauth token!), and use the following snippet to generate and set an aap\_token variable. This ensured that the AAP\_OAUTH\_TOKEN environment variable was empty and unused by automation hub. This also removes the generated token automatically, since these will expire on their own eventually. (I think there’s a method for refreshing tokens instead of deleting/recreating them, but I don’t have a working sample for that) ```yaml - name: Token checkout block: - name: Retrieve OAUTH Token ansible.platform.token: dispatch') }}" description: "Token for AAP CaC dispatch" scope: "write" state: present aap_hostname: "{{ aap_hostname }}" aap_username: "{{ aap_username }}" aap_password: "{{ aap_password }}" aap_validate_certs: "{{ aap_validate_certs }}" register: __alsac_aap__ token when: - aap_hostname | length > 0 - aap_username | length > 0 - aap_password | length > 0 - aap_token | length == 0 check_mode: false - name: Set aap_token ansible.builtin.set_fact: aap_token: "{{ __alsac_aap__ token.ansible_facts.aap_token.token }}" aap_token_id: "{{ __alsac_aap__ token.ansible_facts.aap_token.id }}" cacheable: false when: - aap_token | length == 0 - __alsac_aap__ token.ansible_facts.aap_token.token is defined - __alsac_aap__ token.ansible_facts.aap_token.id is defined check_mode: false - name: Include infra.aap_configuration.dispatch role ansible.builtin.include_role: name: infra.aap_configuration.dispatch always: - name: Remove OAUTH Token ansible.platform.token: existing_token_id: "{{ aap_token_id }}" state: absent aap_hostname: "{{ aap_hostname }}" aap_validate_certs: "{{ aap_validate_certs }}" aap_token: "{{ aap_token }}" register: __alsac_aap__ token when: aap_token_id is defined check_mode: false ``` ---
**Author:** ![system](https://us1.discourse-cdn.com/ansible/original/1X/1882d9a01da5d8996a862359b0913cc568a39b84.svg) [@system](https://forum.ansible.com/u/system)\ **Post date:** [February 4, 2026, 3:08pm UTC](https://forum.ansible.com/t/invalid-authentication-credentials-when-using-infra-aap-configuration-hub-collection-remote/43902/4 "2026-02-04T15:08:59Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.