You can put a discriminator column in the parent if it's analogous to an abstract class in OO. The discriminator has a different value for each child type. If you're clever, it's an fk to a table with one row per child type.
Or you can just rely on that the join of authcredentials to usertype1 succeeds for any usertype1, but for no other child type, and similarly for the other tables. On a left outer join to each child table, all columns (but particularly the id) of the type it isn't are null, and the id it is isn't null. You can then add a calculated column based on this:
select
a.*, b.*, c.*,
case when b.id is not null then 1 else 0 end as is_usertype1,
case when c.id is not null then 1 else 0 end as is_usertype2,
from authcredentials a
left outer join usertype1 b on (a.id = b.authcredential_id )
left outer join usertype2 c on (a.id = c.authcredential_id );
Then make that select a view for ease of use. Inserts will still be to the separate table usertype and usertype2, but then in OO programming, ctors aren't inherited either and two subclasses of a common based don't necessarily have similar ctors.
Just as in C++, where the base class is constructed before the derived class, you'll have to create the parent row bfore you can create a child row (you need the FK).
postgresql explicitly supports table inheritance just like this. Hibernate ORM supports it for mapping tables to Java subclasses.