# SSO & external avatars
**URL:** https://meta.discourse.org/t/sso-external-avatars/192392
**Category:** Feature
**Created:** [June 2, 2021, 11:44am UTC](https://meta.discourse.org/t/sso-external-avatars/192392 "2021-06-02T11:44:45Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@mentalstring](https://meta.discourse.org/u/mentalstring)
#### Post date: [June 2, 2021, 11:44am UTC](https://meta.discourse.org/t/sso-external-avatars/192392/1 "2021-06-02T11:44:45Z")
When using SSO with `sso overrides avatar: true`, Discourse seems to download the avatar and always serve it locally instead of linking directly to the URL provided.
Would it make more sense to allow avatars to serve directly from the `avatar_url` provided? As is, for each avatar shown it hits Discourse backend somewhat needlessly. Perhaps this could be a SSO option?
If the concern is that avatars may go missing, that could be handled with the image `onerror` event that fallback’s `src` to the locally downloaded copy (or show a default one). What I don’t know is if too large avatars images can be constrained with CSS alone.
---
### Author:  [@DrewH](https://meta.discourse.org/u/DrewH)
#### Post date: [June 2, 2021, 2:05pm UTC](https://meta.discourse.org/t/sso-external-avatars/192392/2 "2021-06-02T14:05:09Z")
I believe disabling `download_remote_images_to_local` should solve your issue, although this will also serve images within posts remotely instead of locally.
---
### Author:  [@mentalstring](https://meta.discourse.org/u/mentalstring)
#### Post date: [June 2, 2021, 2:44pm UTC](https://meta.discourse.org/t/sso-external-avatars/192392/3 "2021-06-02T14:44:07Z")
That seems to be only for images in posts — or perhaps for local avatar too, when they are not overwritten by SSO.
---
### Author:  [@DrewH](https://meta.discourse.org/u/DrewH)
#### Post date: [June 2, 2021, 2:49pm UTC](https://meta.discourse.org/t/sso-external-avatars/192392/4 "2021-06-02T14:49:40Z")
Interesting. I know that the OIDC Plugin allows you to override email on every login, maybe something like this would be possible for avatar’s being overwritten by SSO as well.
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [June 2, 2021, 4:24pm UTC](https://meta.discourse.org/t/sso-external-avatars/192392/5 "2021-06-02T16:24:55Z")
> [@mentalstring](#):
>
> Would it make more sense to allow avatars to serve directly from the `avatar_url` provided?
If the SSO avatar is in the format of `https://central.avatar.service/` you can use the `external_system_avatars_url` site setting to get this feature.
---
### Author:  [@mentalstring](https://meta.discourse.org/u/mentalstring)
#### Post date: [June 2, 2021, 5:14pm UTC](https://meta.discourse.org/t/sso-external-avatars/192392/6 "2021-06-02T17:14:31Z")
It’s not in our case (they are served from S3) — and it’s unlikely to usually be in that format so that it can be efficiently cached.
---
### Author:  [@mentalstring](https://meta.discourse.org/u/mentalstring)
#### Post date: [February 19, 2024, 10:52am UTC](https://meta.discourse.org/t/sso-external-avatars/192392/8 "2024-02-19T10:52:08Z")
Following up on this a couple of years later as I think I previously misunderstood something, however, I still think there is still an easy win here for performance.
Previously I thought the avatars were being stored locally (Discourse server itself) and was wondering why they weren’t served directly from the SSO external avatar URL instead of hitting Discourse. However, after some poking, I see now that external avatars coming from SSO are already uploaded to the object storage (e.g. S3) and in the required multiple sizes.
So, if I understand correctly, currently Discourse is proxying avatars from the object storage to the client. However, this behavior seems specific to when using SSO external avatars since avatars here in meta are coming directly from the (CDN’ed) object storage. But when using SSO with external URLs, the avatar URLs are in the form
> [https://discourse-host/user\_avatar/discourse-host/{username}/{size}/{uploadid}\_{version}.png](https://discourse-host/user_avatar/discourse-host/%7Busername%7D/%7Bsize%7D/%7Buploadid%7D_%7Bversion%7D.png)
where it hits rails for every avatar displayed (before being cached by the client).
And if I understand the code, there’s even a setting to allow a redirect instead of proxying it, but at that point it already hit rails and the redirect only adds up time to the load time for the client.
>
Wouldn’t it be faster to just link avatars to the object storage (potentially serving it from a CDN) while freeing some rails resources at the same time? /cc @Falco
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [February 19, 2024, 4:29pm UTC](https://meta.discourse.org/t/sso-external-avatars/192392/9 "2024-02-19T16:29:41Z")
> [@mentalstring](#):
>
> So, if I understand correctly, currently Discourse is proxying avatars from the object storage to the client. However, this behavior seems specific to when using SSO external avatars since avatars here in meta are coming directly from the (CDN’ed) object storage. But when using SSO with external URLs, the avatar URLs are in the form
That’s not the case. By default, Discourse will proxy requests for avatars, as you see on your site.
However, last year, we introduced a setting that can be enabled via the ENV `DISCOURSE_REDIRECT_AVATAR_REQUESTS=1` to trigger the behavior you see here.